DEV Community: Nabeel Krissane

How to Structure a Flutter App Using Clean Architecture

Nabeel Krissane — Thu, 21 May 2026 15:15:24 +0000

Stop building apps that collapse under their own weight. Here's the structure that actually scales.

Introduction

You ship your first Flutter app. It works. Users come in. Features pile up. Six months later, you're afraid to touch anything because one change breaks three other things.

Sound familiar?

This is what happens when Flutter apps grow without a clear architecture. Business logic bleeds into widgets. API calls live inside initState. State management becomes a mess of setState calls scattered everywhere.

The fix is Flutter Clean Architecture — a battle-tested pattern that separates your app into distinct layers, each with one responsibility. In this guide, you'll learn how to set up a production-ready Flutter Clean Architecture boilerplate from scratch, with real code examples, a Laravel backend integration, and authentication built in.

By the end, you'll have a foundation you can drop into any real-world project.

The Problem: Why Flutter Apps Become Unmaintainable

Most Flutter tutorials show you how to build a feature. Almost none show you where to put it.

So developers do what feels natural:

Call the API directly from the widget
Store state in a top-level variable
Put business rules inside the UI layer
Duplicate logic across screens because there's no shared structure

This works fine at 3 screens. At 30 screens, it's a nightmare.

The result: slow onboarding for new teammates, fear of refactoring, and bugs that reappear in unexpected places. The app becomes fragile — and the codebase becomes a liability.

The Solution: Flutter Clean Architecture

Clean Architecture, popularized by Robert C. Martin, organizes code into three independent layers:

Presentation Layer — UI widgets, state management (BLoC/Cubit)
Domain Layer — Business logic, use cases, abstract repository interfaces
Data Layer — API calls, local storage, concrete repository implementations

Each layer only talks to the layer directly below it. Your widgets never know what database you use. Your business logic never imports a Flutter widget. This separation makes testing easy, onboarding fast, and refactoring safe.

Let's build it.

Step 1: Project Setup and Folder Structure

Start by creating your Flutter project:

flutter create my_app
cd my_app

Now structure your lib/ folder like this:

lib/
├── core/
│   ├── error/
│   │   ├── exceptions.dart
│   │   └── failures.dart
│   ├── network/
│   │   └── api_client.dart
│   └── utils/
│       └── constants.dart
├── features/
│   └── auth/
│       ├── data/
│       │   ├── datasources/
│       │   │   └── auth_remote_datasource.dart
│       │   ├── models/
│       │   │   └── user_model.dart
│       │   └── repositories/
│       │       └── auth_repository_impl.dart
│       ├── domain/
│       │   ├── entities/
│       │   │   └── user.dart
│       │   ├── repositories/
│       │   │   └── auth_repository.dart
│       │   └── usecases/
│       │       └── login_usecase.dart
│       └── presentation/
│           ├── bloc/
│           │   ├── auth_bloc.dart
│           │   ├── auth_event.dart
│           │   └── auth_state.dart
│           └── pages/
│               └── login_page.dart
└── injection_container.dart

Visual: Here you should show the full folder tree in your IDE (VS Code or Android Studio). Highlight the features/auth/ directory and show how data, domain, and presentation sit side by side inside each feature.

Step 2: Install Dependencies

Add these to your pubspec.yaml:

dependencies:
  flutter:
    sdk: flutter
  flutter_bloc: ^8.1.3
  dio: ^5.3.2
  get_it: ^7.6.4
  dartz: ^0.10.1
  equatable: ^2.0.5
  shared_preferences: ^2.2.2

dev_dependencies:
  flutter_test:
    sdk: flutter
  mockito: ^5.4.2
  build_runner: ^2.4.6

Then run:

flutter pub get

Why these packages?

flutter_bloc — State management
dio — HTTP client for API calls (works great with Laravel)
get_it — Dependency injection
dartz — Functional error handling with Either<Failure, Success>
equatable — Value equality for entities and states

Step 3: Core Implementation

3.1 Define Failures and Exceptions

In Clean Architecture, errors flow upward through layers. Define them clearly.

// lib/core/error/exceptions.dart
class ServerException implements Exception {
  final String message;
  const ServerException({required this.message});
}

class CacheException implements Exception {
  final String message;
  const CacheException({required this.message});
}

// lib/core/error/failures.dart
import 'package:equatable/equatable.dart';

abstract class Failure extends Equatable {
  final String message;
  const Failure({required this.message});

  @override
  List<Object> get props => [message];
}

class ServerFailure extends Failure {
  const ServerFailure({required super.message});
}

class CacheFailure extends Failure {
  const CacheFailure({required super.message});
}

3.2 Set Up the API Client (Dio + Laravel)

// lib/core/network/api_client.dart
import 'package:dio/dio.dart';

class ApiClient {
  late final Dio _dio;

  ApiClient() {
    _dio = Dio(
      BaseOptions(
        baseUrl: 'https://your-laravel-app.com/api',
        connectTimeout: const Duration(seconds: 10),
        receiveTimeout: const Duration(seconds: 10),
        headers: {
          'Accept': 'application/json',
          'Content-Type': 'application/json',
        },
      ),
    );

    _dio.interceptors.add(
      InterceptorsWrapper(
        onRequest: (options, handler) {
          // Attach Bearer token for Laravel Sanctum / Passport
          final token = ''; // retrieve from storage
          if (token.isNotEmpty) {
            options.headers['Authorization'] = 'Bearer $token';
          }
          return handler.next(options);
        },
        onError: (DioException e, handler) {
          return handler.next(e);
        },
      ),
    );
  }

  Dio get dio => _dio;
}

Visual: Here you should show an API response flow diagram. Arrow from Flutter app → Dio Client → Laravel /api/login → JSON response → model parsing → entity → BLoC state.

Step 4: The Authentication Feature — End to End

This is the most common real-world feature. Let's build it across all three layers.

4.1 Domain Layer — The Pure Core

The domain layer has zero Flutter or Dart-specific framework dependencies. It's plain Dart.

// lib/features/auth/domain/entities/user.dart
import 'package:equatable/equatable.dart';

class User extends Equatable {
  final int id;
  final String name;
  final String email;
  final String token;

  const User({
    required this.id,
    required this.name,
    required this.email,
    required this.token,
  });

  @override
  List<Object?> get props => [id, email, token];
}

// lib/features/auth/domain/repositories/auth_repository.dart
import 'package:dartz/dartz.dart';
import '../../../../core/error/failures.dart';
import '../entities/user.dart';

abstract class AuthRepository {
  Future<Either<Failure, User>> login({
    required String email,
    required String password,
  });
  Future<Either<Failure, void>> logout();
}

// lib/features/auth/domain/usecases/login_usecase.dart
import 'package:dartz/dartz.dart';
import '../../../../core/error/failures.dart';
import '../entities/user.dart';
import '../repositories/auth_repository.dart';

class LoginUseCase {
  final AuthRepository repository;

  LoginUseCase(this.repository);

  Future<Either<Failure, User>> call({
    required String email,
    required String password,
  }) async {
    return await repository.login(email: email, password: password);
  }
}

4.2 Data Layer — API Integration with Laravel

// lib/features/auth/data/models/user_model.dart
import '../../domain/entities/user.dart';

class UserModel extends User {
  const UserModel({
    required super.id,
    required super.name,
    required super.email,
    required super.token,
  });

  factory UserModel.fromJson(Map<String, dynamic> json) {
    return UserModel(
      id: json['user']['id'],
      name: json['user']['name'],
      email: json['user']['email'],
      token: json['token'],
    );
  }

  Map<String, dynamic> toJson() {
    return {
      'id': id,
      'name': name,
      'email': email,
      'token': token,
    };
  }
}

// lib/features/auth/data/datasources/auth_remote_datasource.dart
import '../../../../core/error/exceptions.dart';
import '../../../../core/network/api_client.dart';
import '../models/user_model.dart';

abstract class AuthRemoteDataSource {
  Future<UserModel> login({required String email, required String password});
}

class AuthRemoteDataSourceImpl implements AuthRemoteDataSource {
  final ApiClient apiClient;

  AuthRemoteDataSourceImpl(this.apiClient);

  @override
  Future<UserModel> login({
    required String email,
    required String password,
  }) async {
    try {
      final response = await apiClient.dio.post(
        '/login',
        data: {'email': email, 'password': password},
      );

      if (response.statusCode == 200) {
        return UserModel.fromJson(response.data);
      } else {
        throw ServerException(message: 'Login failed');
      }
    } catch (e) {
      throw ServerException(message: e.toString());
    }
  }
}

// lib/features/auth/data/repositories/auth_repository_impl.dart
import 'package:dartz/dartz.dart';
import '../../../../core/error/exceptions.dart';
import '../../../../core/error/failures.dart';
import '../../domain/entities/user.dart';
import '../../domain/repositories/auth_repository.dart';
import '../datasources/auth_remote_datasource.dart';

class AuthRepositoryImpl implements AuthRepository {
  final AuthRemoteDataSource remoteDataSource;

  AuthRepositoryImpl(this.remoteDataSource);

  @override
  Future<Either<Failure, User>> login({
    required String email,
    required String password,
  }) async {
    try {
      final user = await remoteDataSource.login(
        email: email,
        password: password,
      );
      return Right(user);
    } on ServerException catch (e) {
      return Left(ServerFailure(message: e.message));
    }
  }

  @override
  Future<Either<Failure, void>> logout() async {
    // Clear token from storage
    return const Right(null);
  }
}

4.3 Presentation Layer — BLoC + UI

// lib/features/auth/presentation/bloc/auth_event.dart
import 'package:equatable/equatable.dart';

abstract class AuthEvent extends Equatable {
  @override
  List<Object?> get props => [];
}

class LoginRequested extends AuthEvent {
  final String email;
  final String password;

  LoginRequested({required this.email, required this.password});

  @override
  List<Object?> get props => [email, password];
}

// lib/features/auth/presentation/bloc/auth_state.dart
import 'package:equatable/equatable.dart';
import '../../domain/entities/user.dart';

abstract class AuthState extends Equatable {
  @override
  List<Object?> get props => [];
}

class AuthInitial extends AuthState {}
class AuthLoading extends AuthState {}

class AuthSuccess extends AuthState {
  final User user;
  AuthSuccess(this.user);

  @override
  List<Object?> get props => [user];
}

class AuthFailure extends AuthState {
  final String message;
  AuthFailure(this.message);

  @override
  List<Object?> get props => [message];
}

// lib/features/auth/presentation/bloc/auth_bloc.dart
import 'package:flutter_bloc/flutter_bloc.dart';
import '../../domain/usecases/login_usecase.dart';
import 'auth_event.dart';
import 'auth_state.dart';

class AuthBloc extends Bloc<AuthEvent, AuthState> {
  final LoginUseCase loginUseCase;

  AuthBloc({required this.loginUseCase}) : super(AuthInitial()) {
    on<LoginRequested>(_onLoginRequested);
  }

  Future<void> _onLoginRequested(
    LoginRequested event,
    Emitter<AuthState> emit,
  ) async {
    emit(AuthLoading());

    final result = await loginUseCase(
      email: event.email,
      password: event.password,
    );

    result.fold(
      (failure) => emit(AuthFailure(failure.message)),
      (user) => emit(AuthSuccess(user)),
    );
  }
}

// lib/features/auth/presentation/pages/login_page.dart
import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import '../bloc/auth_bloc.dart';
import '../bloc/auth_event.dart';
import '../bloc/auth_state.dart';

class LoginPage extends StatefulWidget {
  const LoginPage({super.key});

  @override
  State<LoginPage> createState() => _LoginPageState();
}

class _LoginPageState extends State<LoginPage> {
  final _emailController = TextEditingController();
  final _passwordController = TextEditingController();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Login')),
      body: BlocConsumer<AuthBloc, AuthState>(
        listener: (context, state) {
          if (state is AuthSuccess) {
            Navigator.pushReplacementNamed(context, '/home');
          } else if (state is AuthFailure) {
            ScaffoldMessenger.of(context).showSnackBar(
              SnackBar(content: Text(state.message)),
            );
          }
        },
        builder: (context, state) {
          return Padding(
            padding: const EdgeInsets.all(24.0),
            child: Column(
              mainAxisAlignment: MainAxisAlignment.center,
              children: [
                TextField(
                  controller: _emailController,
                  decoration: const InputDecoration(labelText: 'Email'),
                  keyboardType: TextInputType.emailAddress,
                ),
                const SizedBox(height: 16),
                TextField(
                  controller: _passwordController,
                  decoration: const InputDecoration(labelText: 'Password'),
                  obscureText: true,
                ),
                const SizedBox(height: 24),
                if (state is AuthLoading)
                  const CircularProgressIndicator()
                else
                  ElevatedButton(
                    onPressed: () {
                      context.read<AuthBloc>().add(
                        LoginRequested(
                          email: _emailController.text,
                          password: _passwordController.text,
                        ),
                      );
                    },
                    child: const Text('Login'),
                  ),
              ],
            ),
          );
        },
      ),
    );
  }
}

Visual: Here you should show the Flutter login screen UI — a clean form with email/password fields, a loading indicator state, and a success navigation transition. Screenshot from the emulator or device.

4.4 Dependency Injection with GetIt

Wire everything together in one place:

// lib/injection_container.dart
import 'package:get_it/get_it.dart';
import 'core/network/api_client.dart';
import 'features/auth/data/datasources/auth_remote_datasource.dart';
import 'features/auth/data/repositories/auth_repository_impl.dart';
import 'features/auth/domain/repositories/auth_repository.dart';
import 'features/auth/domain/usecases/login_usecase.dart';
import 'features/auth/presentation/bloc/auth_bloc.dart';

final sl = GetIt.instance;

Future<void> init() async {
  // BLoC
  sl.registerFactory(() => AuthBloc(loginUseCase: sl()));

  // Use Cases
  sl.registerLazySingleton(() => LoginUseCase(sl()));

  // Repositories
  sl.registerLazySingleton<AuthRepository>(
    () => AuthRepositoryImpl(sl()),
  );

  // Data Sources
  sl.registerLazySingleton<AuthRemoteDataSource>(
    () => AuthRemoteDataSourceImpl(sl()),
  );

  // Core
  sl.registerLazySingleton(() => ApiClient());
}

Call init() in your main.dart:

// lib/main.dart
import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'features/auth/presentation/bloc/auth_bloc.dart';
import 'features/auth/presentation/pages/login_page.dart';
import 'injection_container.dart' as di;

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await di.init();
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Clean App',
      home: BlocProvider(
        create: (_) => di.sl<AuthBloc>(),
        child: const LoginPage(),
      ),
    );
  }
}

Laravel Backend — What the API Should Return

Your Laravel /api/login endpoint should return:

{
  "token": "1|abcdefg12345",
  "user": {
    "id": 1,
    "name": "Ahmed Ben Ali",
    "email": "ahmed@example.com"
  }
}

A simple Laravel controller using Sanctum:

// app/Http/Controllers/Api/AuthController.php
<?php

namespace App\Http\Controllers\Api;

use App\Http\Controllers\Controller;
use App\Models\User;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;

class AuthController extends Controller
{
    public function login(Request $request)
    {
        $request->validate([
            'email'    => 'required|email',
            'password' => 'required',
        ]);

        $user = User::where('email', $request->email)->first();

        if (! $user || ! Hash::check($request->password, $user->password)) {
            return response()->json([
                'message' => 'Invalid credentials',
            ], 401);
        }

        return response()->json([
            'token' => $user->createToken('flutter-app')->plainTextToken,
            'user'  => $user->only(['id', 'name', 'email']),
        ]);
    }
}

Visual: Here you should show the API response flow — diagram with Laravel Sanctum token generation on the server side, and the Flutter model parsing the JSON into a UserModel, then converting to a User entity.

Common Mistakes Developers Make

1. Importing Flutter packages in the domain layer

The domain layer must stay pure Dart. Never import package:flutter there. If you need BuildContext or widgets in a use case, you've gone wrong.

2. Putting business logic in BLoC

BLoC handles state transitions, not business rules. The logic belongs in use cases. BLoC just calls the use case and emits a new state.

3. Skipping the repository interface

Some developers implement the repository directly without an abstract class. This makes testing impossible — you can't mock a concrete class cleanly.

4. One giant feature folder

Dumping all features into a single lib/screens/ folder defeats the purpose. One folder per feature, with its own data/domain/presentation split.

5. Not handling Left (failures)

Using dartz's Either is pointless if you only handle Right. Always .fold() and handle both cases.

Best Practices

Test at the use case level. Use cases are pure Dart — easy to unit test without Flutter Test infrastructure.
One use case per action. LoginUseCase, LogoutUseCase, RegisterUseCase — not a AuthUseCase that does everything.
Use Equatable on entities and states. BLoC won't rebuild on state changes unless equality works correctly.
Register BLoCs as Factory, singletons as LazySingleton. BLoCs hold UI state — they should be created fresh per screen.
Keep your ApiClient in core. Don't duplicate Dio setup per feature.
Store the token securely. Use flutter_secure_storage for the Bearer token, not SharedPreferences.

Real-World Use Cases

This architecture isn't academic. It's what powers serious production apps:

SaaS mobile apps — Multi-tenant platforms where auth, billing, and user roles need clear separation between layers.

E-commerce apps — Product listings, cart, and checkout each live as independent features. One team can work on cart without touching auth.

Admin dashboards — Flutter Web admin panels backed by Laravel APIs use this exact structure for scalable role-based access control.

Healthcare apps — Where testability and audit trails are non-negotiable, Clean Architecture is the standard.

Any app that needs to grow, be tested, or be maintained by more than one developer benefits from this structure.

Conclusion

Flutter Clean Architecture isn't about following a textbook pattern for its own sake. It's about building apps that don't become unmanageable.

With this setup, you get:

A codebase you can test at every layer
Features that can be built and deployed independently
A clear contract between your Flutter app and any backend (like Laravel)
A structure any developer can onboard into quickly

The boilerplate feels like overhead at first. Within weeks on a real project, it saves you hours.

Start with auth. Add your next feature using the same pattern. The architecture will carry you.

Found this useful? Follow for more practical Flutter and Laravel content. Clap if it saved you time — it helps others find this guide.

How I Would Get My First Flutter Client in 30 Days (Beginner Plan)

Nabeel Krissane — Wed, 06 May 2026 19:07:38 +0000

Most Flutter developers don’t fail because of coding.

They fail because they don’t know how to turn their skills into money.

You learn Flutter, build a few apps… and then what?

No clients.
No income.
No direction.

If I had to start again from zero, here’s exactly what I would do to get my first Flutter client in 30 days.

The Real Problem
The issue isn’t Flutter.

It’s this:

You don’t know what to offer
You don’t know where to find clients
You don’t know how to price your work
You wait until you're “ready”

And that delays everything.

Step 1: Stop Trying to Be Perfect

You don’t need to be an expert.

You need to be useful.

Start with simple services like:

Fixing bugs
Building basic UI screens
Connecting APIs
Converting websites into mobile apps

That’s enough to get paid.

Step 2: Create One Simple Portfolio

Don’t overcomplicate this.

Build 1 solid project:

Example:

A delivery app UI
A booking app
A simple e-commerce app

Upload it to GitHub and record a quick demo.

That’s your proof.

Step 3: Price Smart (Not High)

Your first goal is not profit.

It’s traction.

Start with:

$100 – $300 small jobs
$300 – $700 simple apps

This helps you:

Get reviews
Build confidence
Understand clients

You can raise prices later.

Step 4: Find Clients Every Day

This is where most people fail.

You need daily action.

Places to find leads:

Upwork (send 5–10 proposals daily)

Facebook business groups
LinkedIn outreach
Local businesses
Indie hackers / startup founders

Example outreach:

“Hi, I saw your business and noticed you don’t have a mobile app. I’m a Flutter developer and can build a simple app to help your customers engage more easily. Let me know if you’re interested.”

Keep it simple. No long messages.

Step 5: Focus on Communication

Clients don’t hire the best developer.

They hire the one who:

Replies fast
Understands their needs
Sounds reliable

This alone can beat more experienced devs.

Step 6: Avoid These Beginner Mistakes

Waiting to be “ready”
Building 10 projects but never selling
Charging too low forever
Ignoring outreach
Giving up too early

Consistency wins.

🚀 If You Want a Shortcut

When I was figuring this out, I realized something:

Most beginners don’t need more tutorials…
They need a clear system to get clients and start earning.

That’s why I created this:

cimoradevtools.gumroad.com

The Flutter Freelancer Starter Bundle includes:

Client acquisition guide
Pricing strategy for beginners
Outreach & proposal templates
Practical resources to start faster

It’s designed to help you skip months of confusion and start taking action immediately.
30-Day Action Plan

If you follow this, you’ll see results:

Week 1

Build 1 project
Prepare GitHub + demo

Week 2

Start outreach (5–10 messages/day)
Apply to jobs

Week 3

Improve proposals
Talk to real clients

Week 4

Close your first deal

Final Thought

Your first client won’t come from luck.

It comes from:

Showing up daily
Offering simple value
Taking action before you feel ready

Flutter is just the tool.

Your consistency is what makes you money.

Stopping Fraud Before It Starts: How AI Detects Fake Documents

Nabeel Krissane — Thu, 02 Oct 2025 19:04:22 +0000

Every platform that deals with user identity faces the same challenge:

How do you know if someone is who they say they are?

From financial apps to online marketplaces, fraudsters constantly try to bypass verification by submitting fake IDs, passports, or altered documents. Traditionally, the process of detecting these fakes required manual review — a slow, expensive, and error-prone method.

Today, thanks to AI, we can stop fraud before it starts.

The Growing Problem of Fake Documents

Fake IDs and forged passports aren’t just a problem for governments. Online businesses face them daily:

Marketplaces dealing with fake seller accounts.
Fintech apps preventing fraudulent transactions.
Social platforms stopping bots from pretending to be real users.

The cost of letting a fake slip through isn’t just financial — it damages user trust and makes compliance with regulations harder.

Why AI Is a Game-Changer

Artificial Intelligence (AI) can process and analyze images far faster and more accurately than humans. When applied to identity verification, AI can:

Detect tampered or photoshopped areas.
Recognize whether a document matches real government-issued templates.
Verify if an image truly contains an ID or passport at all.

Instead of relying on people to spot subtle mistakes, AI does it automatically — and in real-time.

How It Works in Practice

Here’s an example using Deep Detect, an AI-powered API that makes document verification simple.

With just one request, you can check if an uploaded file contains a valid ID or passport:


bash
curl -X POST "https://api.deepdetect.ai/check" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/uploaded-passport.jpg",
    "service": "id-detection"
  }'

Build an ID Document Detection App in Minutes with Deep Detect

Nabeel Krissane — Sat, 27 Sep 2025 15:41:51 +0000

Want to automatically detect ID documents (passports, ID cards, driver licenses) in your app? With Deep Detect you can set up a detection flow in under 15 minutes.

1. Get your API key & services

Sign up at deepdetect.app
You’ll get an API key.
To list available detection services (like ID documents, faces, license plates, etc.), call the services endpoint:

curl --location 'https://deepdetect.app/api/get-services' \
  --header 'dd-api-key: YOUR_API_KEY'

This returns service codes you’ll use when analyzing images.

2. Call the analyze-image endpoint

Basic request (replace SERVICE-CODE with your ID detection service code):

curl --location 'https://deepdetect.app/api/analyze-image' \
  --header 'dd-api-key: YOUR_API_KEY' \
  --form 'image=@"/path/to/file.jpg"' \
  --form 'action="SERVICE-CODE"'

The API responds with predictions + confidence scores. You can decide thresholds (e.g., passport confidence > 0.7).

3. Add a tiny proxy server

Never expose your API key in frontend code. Quick Node.js proxy example:

app.post('/api/detect-id', upload.single('image'), async (req, res) => {
  const form = new FormData();
  form.append('image', fs.createReadStream(req.file.path));
  form.append('action', process.env.DD_SERVICE);

  const ddRes = await axios.post('https://deepdetect.app/api/analyze-image', form, {
    headers: { 'dd-api-key': process.env.DD_API_KEY, ...form.getHeaders() },
  });

  res.json(ddRes.data);
});

Frontend just uploads to /api/detect-id and shows the result.

4. That’s it 🎉

List services with /api/services.
Detect ID documents with /api/analyze-image.
Wrap it in a small backend proxy.
Use predictions + confidence scores to flag or process ID documents in your app. In minutes, you’ve got a working ID document detection app powered by Deep Detect.

How to Detect NSFW Images in Your Platform Using Deep Detect API

Nabeel Krissane — Sun, 22 Jun 2025 15:46:30 +0000

Ensuring a safe and user-friendly environment on your platform is more critical than ever, especially with the rise of user-generated content across social media, forums, and e-commerce sites. NSFW (Not Safe For Work) images—encompassing explicit adult content, nudity, or sexual activity—can alienate users, damage your brand reputation, and even lead to legal challenges. Fortunately, the Deep Detect API offers a robust solution to detect and filter such content seamlessly. In this post, we’ll dive into how you can integrate this powerful tool into your platform to enhance safety and compliance.

What is Deep Detect?

Deep Detect is a state-of-the-art SaaS platform designed to provide advanced image analysis services tailored for content moderation, security, and compliance. One of its key offerings is the NSFW detection service, accessible via the service code XeAkkf. This feature leverages cutting-edge AI to identify inappropriate content with high accuracy, making it an essential tool for platforms aiming to maintain strict moderation policies. Beyond NSFW detection, Deep Detect supports a wide range of services, from identifying weapons and hate symbols to detecting AI-generated images, offering a comprehensive moderation suite.

Why NSFW Detection Matters

In today’s digital landscape, user trust is paramount. Unmoderated NSFW content can drive away loyal users, attract negative attention, and result in regulatory fines, especially under laws like the EU’s Digital Services Act. Manually reviewing images is time-consuming and impractical for scaling platforms. The Deep Detect API automates this process, allowing you to focus on growth while ensuring a safe environment for your community.

Getting Started with Deep Detect

To harness the power of Deep Detect, you’ll need to sign up at deepdetect.app to obtain an API key. This key unlocks access to all available services, including NSFW detection. The platform offers a flexible pay-as-you-go pricing model, making it accessible for startups and established businesses alike. Once you have your API key, you’re ready to integrate the service into your application.

Python Integration Example

Below is a detailed Python script using the requests library to detect NSFW images with the Deep Detect API. Replace XXX with your actual API key and update the file_path to point to your image file:

import requests

url = "https://deepdetect.app/api/analyze-image"
api_key = "XXX"
file_path = "/path/to/file"

with open(file_path, "rb") as image_file:
    files = {"image": image_file}
    data = {"action": "XeAkkf"}
    headers = {"Accept": "application/json", "dd-api-key": api_key}

    response = requests.post(url, files=files, data=data, headers=headers)

    if response.status_code == 200:
        result = response.json()
        print("NSFW Detection Result:", result)
        if result.get("is_nsfw", False):
            print("Image contains NSFW content. Take action!")
        else:
            print("Image is safe.")
    else:
        print("Error:", response.status_code, response.text)

How to Use the Script

Install Dependencies: Ensure you have requests installed (pip install requests).
Update Credentials: Insert your API key and the path to the image you want to analyze.
Run the Script: Execute it to get a JSON response indicating NSFW status.
Act on Results: Use the output to flag or remove inappropriate content in your platform.

How the Deep Detect API Works

The process is straightforward:

Upload the Image: The script sends the image file to the API endpoint.
Specify the Action: The action parameter set to XeAkkf triggers the NSFW detection service.
Receive the Response: The API returns a JSON object with details, including a boolean indicating NSFW content presence.
Automate Moderation: Integrate the result into your workflow to block or review flagged images.

Benefits of Using Deep Detect

High Accuracy: Powered by advanced AI, it minimizes false positives and negatives.
Ease of Integration: The API is developer-friendly and works with any programming language.
Scalability: The pay-as-you-go plan adapts to your usage, perfect for growing platforms.
Comprehensive Coverage: Beyond NSFW, detect violence (5fK43A), hate symbols (XTv6pq), or copyrighted content (ZEuGTB).
Time-Saving: Automates what would otherwise require extensive manual review.

Expanding Your Moderation Strategy

While NSFW detection is a great starting point, consider combining it with other Deep Detect services for a holistic approach. For instance:

Use 5fK43A to detect violence or gore.
Employ XTv6pq to identify hate symbols.
Leverage ZEuGTB to protect against copyrighted material.

This multi-layered moderation ensures your platform remains safe and compliant across all content types.

Next Steps

Integrate the Deep Detect API into your platform’s content moderation pipeline today. Start with a small test using the provided script, then scale to real-time analysis as needed. Visit deepdetect.app to sign up for a free trial and explore the full range of features. Join a growing community of developers and businesses leveraging Deep Detect to create safer digital spaces.

Happy coding, and let’s build a safer internet together with Deep Detect!

How to Host a Flutter Web App on Microsoft Azure

Nabeel Krissane — Wed, 22 Mar 2023 09:08:12 +0000

Flutter has become an increasingly popular framework for developing cross-platform mobile applications. In addition to mobile apps, Flutter also supports web app development, enabling developers to create responsive and engaging web experiences. Microsoft Azure is a cloud computing platform that provides various services for hosting, deploying, and managing web applications. In this article, we'll guide you through the process of hosting a Flutter web app on Microsoft Azure.

Prerequisites

Before diving into the process, make sure you have the following:

A Flutter web app: Create a new Flutter web app or use an existing one.
Microsoft Azure account: Sign up for a free trial or use your existing account.
Azure CLI: Install the Azure Command-Line Interface (CLI) on your machine.

Build the Flutter Web App

To deploy the Flutter web app, first, you need to build it for production. Open a terminal and navigate to the root directory of your Flutter project. Run the following command:
flutter build web
This command will generate the necessary files for your web app in the build/web directory.

Set Up a Storage Account on Azure

A Storage Account in Azure is used to store and manage your web app's files. To create a new storage account, follow these steps:

Sign in to the Azure portal.
Click on "Create a resource" in the left sidebar.
Search for "Storage Account" and click "Create."
Fill in the required fields, such as subscription, resource group, account name, and location. Click "Review + create" and then "Create" to finalize.

Enable Static Website Hosting

Once your storage account is created, enable static website hosting:

Navigate to your storage account in the Azure portal.
Click on "Static website" under the "Settings" section.
Set "Static website" to "Enabled.".
Set "Index document name" to "index.html" and "Error document path" to "404.html."
Click "Save."

Deploy Your Flutter Web App

Now that your storage account is set up and static website hosting is enabled, you can deploy your Flutter web app. First, sign in to Azure CLI using:
az login
Once logged in, navigate to the build/web directory of your Flutter project and run the following command:
az storage blob upload-batch -s . -d '$web' --account-name <YourStorageAccountName> --account-key <YourStorageAccountKey>
Replace <YourStorageAccountName> and <YourStorageAccountKey> with the appropriate values from your storage account. You can find these in the "Access keys" section of your storage account settings in the Azure portal.

Access Your Flutter Web App

After deploying your web app, you can access it using the provided URL. In the Azure portal, navigate to your storage account and click on "Static website" under the "Settings" section. You'll see the "Primary endpoint" URL. Open this URL in a web browser to see your Flutter web app in action.
And voila your web app is hosted on Microsoft Azure!