DEV Community: Nabeel Krissane

Stop Asking Cursor to “Build This”, Use These Prompts Instead

Nabeel Krissane — Tue, 08 Sep 2026 08:00:00 +0000

If you've ever typed "build this feature" into Cursor and gotten back a half-working mess, you're not alone. Most developers use AI coding assistants the same way they'd talk to a junior intern with no context — vague instructions, no constraints, no examples.

The result? Broken imports, inconsistent architecture, and code you end up rewriting anyway.

In this guide, you'll learn exactly how to prompt Cursor AI to generate production-ready code — not just "something that runs." We'll cover the core problem with vague prompting, a repeatable prompting framework, and real Flutter and Laravel code examples you can copy today.

By the end, you'll know how to turn Cursor from a guessing machine into a reliable coding partner.

The Problem: Why "Build This" Prompts Fail

When you type something like:

"Build a login screen"

Cursor has almost no context. It doesn't know:

Your project's folder structure
Your state management approach (Provider? Riverpod? Bloc?)
Your naming conventions
Whether you use a service layer or call APIs directly in widgets
Your error-handling pattern

So it fills in the blanks with generic assumptions — often based on outdated tutorials or mismatched patterns. That's why the output feels "almost right" but never quite fits your codebase.

Why Developers Keep Doing This

It's not laziness — it's a habit carried over from Google searches and Stack Overflow, where short, vague queries usually work fine. But AI code generation isn't search. It's instruction-following, and instructions need structure to be useful.

The common mistakes look like this:

Asking for a whole feature in one prompt instead of breaking it into steps
Not specifying architecture, packages, or naming conventions
Not giving Cursor an example of existing code style
Never asking Cursor to explain its reasoning before generating code
Accepting the first output without reviewing or iterating

The Solution: A Prompting Framework, Not a Prompt

Instead of one big vague request, treat Cursor like a pair programmer who needs a brief. Give it:

Context — what the project is, what stack you use
Constraints — architecture, naming, folder structure
Scope — one small task at a time, not a whole feature
Example — a snippet of existing code style, if possible
Output format — ask for explanations, not just code

This turns Cursor from a "guesser" into a "follower of your standards."

Step-by-Step Implementation

Step 1: Setup — Give Cursor Project Context First

Before asking for any code, prime Cursor with a system-level prompt. In Cursor, you can do this in a .cursorrules file at your project root, or as the first message in a new chat.

# .cursorrules

This is a Flutter project using:
- Clean Architecture (data / domain / presentation layers)
- Riverpod for state management
- Dio for networking
- Freezed for models

Rules:
- Always place API calls inside a repository class, never inside widgets
- Use snake_case for file names, PascalCase for class names
- Always return a Result<T> type instead of throwing raw exceptions
- Prefer StatelessWidget + Riverpod over StatefulWidget

This single file changes everything. Now every prompt you write is interpreted inside your project's rules, not generic defaults.

Step 2: Configuration — Scope the Task Narrowly

Instead of:

"Build user authentication"

Break it down:

"Create a AuthRepository class that handles login via POST /api/login, following the existing repository pattern in lib/data/repositories/user_repository.dart. Return a Result<User> type."

Narrow scope = fewer wrong assumptions.

Step 3: Core Implementation — The Actual Prompt Template

Here's a reusable prompt template for feature work:

Context: [what this feature does and where it fits]
Constraints: [architecture, packages, patterns to follow]
Task: [the single, specific thing to build]
Reference: [existing file/class to match style with]
Output: Generate the code, then explain any assumptions you made.

Real example — Flutter login repository:

Context: I need a login feature for a Flutter app using Clean Architecture.
Constraints: Use Dio for networking, Riverpod for state, return Result<T> instead of throwing.
Task: Create an AuthRepository with a login(email, password) method.
Reference: Follow the pattern in lib/data/repositories/user_repository.dart
Output: Generate the code, then explain any assumptions you made.

Cursor's output (cleaned up):

// lib/data/repositories/auth_repository.dart

class AuthRepository {
  final Dio _dio;

  AuthRepository(this._dio);

  Future<Result<User>> login(String email, String password) async {
    try {
      final response = await _dio.post('/api/login', data: {
        'email': email,
        'password': password,
      });

      final user = User.fromJson(response.data['user']);
      return Result.success(user);
    } on DioException catch (e) {
      return Result.failure(e.message ?? 'Login failed');
    }
  }
}

Notice the difference: it follows a repository pattern, uses a Result<T> wrapper, and matches your existing conventions — because you told it to.

Real example — Laravel API endpoint:

Context: Laravel 11 API using Sanctum for auth, following Repository + Service pattern.
Constraints: Controllers should stay thin; business logic goes in Service classes.
Task: Create a login endpoint that returns a token on success.
Reference: Follow the structure in app/Services/UserService.php
Output: Generate the code, then explain any assumptions you made.

<?php
// app/Services/AuthService.php

namespace App\Services;

use App\Models\User;
use Illuminate\Support\Facades\Hash;
use Illuminate\Validation\ValidationException;

class AuthService
{
    public function login(array $credentials): array
    {
        $user = User::where('email', $credentials['email'])->first();

        if (!$user || !Hash::check($credentials['password'], $user->password)) {
            throw ValidationException::withMessages([
                'email' => ['Invalid credentials.'],
            ]);
        }

        $token = $user->createToken('api-token')->plainTextToken;

        return [
            'user' => $user,
            'token' => $token,
        ];
    }
}

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

namespace App\Http\Controllers;

use App\Services\AuthService;
use Illuminate\Http\Request;

class AuthController extends Controller
{
    public function __construct(private AuthService $authService) {}

    public function login(Request $request)
    {
        $validated = $request->validate([
            'email' => 'required|email',
            'password' => 'required|string',
        ]);

        $result = $this->authService->login($validated);

        return response()->json($result);
    }
}

The controller stays thin, the logic lives in a service — because the prompt told Cursor to respect that separation.

Step 4: Final Integration — Ask for a Review Pass

After Cursor generates code, don't stop there. Run a follow-up prompt:

Review the code you just generated. Check for:
- Error handling gaps
- Naming consistency with the rest of the project
- Any hardcoded values that should be constants or env variables

This second pass catches issues Cursor's first draft usually misses.

Common Mistakes Developers Make with Cursor

1. Asking for entire features in one prompt
This overwhelms context and produces inconsistent files. Break features into 3–5 smaller prompts instead.

2. Never providing a style reference
Without an example file, Cursor defaults to generic patterns that don't match your codebase.

3. Skipping the .cursorrules file
This is the single most underused feature. It's the difference between re-explaining your stack every time and having Cursor "just know" it.

4. Accepting output without reviewing
AI-generated code can look correct while quietly missing edge cases like null checks or expired tokens.

5. Not specifying the output format
If you don't ask for explanations, Cursor gives you code with zero reasoning — making it harder to trust or debug later.

Best Practices for Prompting Cursor

One task per prompt. Small, scoped requests produce more reliable code.
Keep a living .cursorrules file. Update it as your architecture evolves.
Always reference an existing file. This anchors style and structure.
Ask "why" before "what." Prompt Cursor to explain its approach before generating code for complex logic.
Use Result/Either types instead of raw exceptions in both Flutter and Laravel — it keeps error handling predictable and easy for AI to replicate consistently.
Version your prompts. Save your best prompt templates in a /prompts folder in your repo so your team reuses them.

Visual Explanation (What to Include Here)

Here you should show a side-by-side screenshot: a vague "build this" prompt output on the left, vs. a structured prompt output on the right, highlighting the architecture differences.

Here you should show the .cursorrules file open in Cursor's file explorer, with the project folder structure visible in the sidebar.

Here you should show a diagram of the prompting flow: Context → Constraints → Scope → Reference → Output, as a simple horizontal flowchart.

Real-World Use Case

This prompting approach isn't just for solo side projects — it's exactly how teams shipping production software use AI tools:

SaaS apps: Teams use .cursorrules to enforce consistent service/repository patterns across dozens of contributors.
Mobile apps: Flutter teams use scoped prompts to generate feature modules that match Clean Architecture without manual boilerplate.
Admin dashboards: Laravel teams use structured prompts to keep controllers thin and logic testable, even when AI writes most of the first draft.
Production systems: Companies increasingly review AI-generated PRs the same way they review human ones — which only works if the AI output already follows house style.

Conclusion

The difference between frustrating AI output and genuinely useful code isn't the model — it's the prompt.

Stop typing "build this" and expecting Cursor to read your mind. Give it context, constraints, scope, and a reference file. Ask it to explain its reasoning. Review its output like you would a junior developer's PR.

Do this consistently, and Cursor stops being a slot machine and starts being an actual extension of your team.

Want to Build React Apps Faster with AI?

Learning React is one thing. Building real-world applications efficiently is another.

You can use ChatGPT, Claude, and Cursor to write code, debug issues, refactor components, generate features, and speed up your development but getting useful results depends heavily on how you prompt AI.

That’s why I created The Ultimate React + Cursor Prompt Library (1000+ AI Prompts) a practical collection of AI prompts designed specifically for React developers.

Inside the library, you’ll find 1,000+ practical prompts covering React development, UI components, debugging, refactoring, performance optimization, API integration, state management, testing, architecture, and more.

Each prompt is designed to help you get better results from AI coding assistants like Cursor, ChatGPT, and Claude, so you can spend less time figuring out what to ask and more time building.

Instead of staring at a blank Cursor chat wondering what prompt to write, you can start with proven prompts and adapt them to your own projects.

Whether you’re building a SaaS, freelance project, startup, dashboard, or personal application, this library can help you code faster, solve problems quicker, and get more out of AI-assisted development.

👉 The Ultimate React + Cursor Prompt Library: 1000+ AI Prompts →

15 Cursor Prompts Every React Developer Should Have Saved

Nabeel Krissane — Sat, 05 Sep 2026 08:00:00 +0000

Introduction

You open Cursor, type a vague request, and get back code that half-works, ignores your project structure, or hallucinates a hook that doesn't exist.

Every React developer using AI-assisted coding tools has hit this wall. The problem usually isn't Cursor — it's the prompt.

A well-structured Cursor prompt can turn a 20-minute refactor into a 30-second task. A lazy one wastes your time debugging AI-generated bugs.

In this article, you'll get 15 battle-tested Cursor prompts for React development — for components, hooks, performance, testing, and debugging — that you can copy, save, and reuse in every project.

By the end, you'll have a personal "prompt library" that makes Cursor feel like a senior React engineer sitting next to you.

Why Most Cursor Prompts Fail for React Projects

Most developers treat Cursor like a search engine. They type short, generic requests such as "make a login form" or "fix this bug."

The AI has no context about your component structure, state management approach, or styling system, so it guesses — and guesses are where bugs come from.

Three common mistakes:

No context: not mentioning React version, TypeScript, or state library
No constraints: not specifying performance, accessibility, or file structure rules
No examples: not showing existing code patterns the AI should follow

Fixing this isn't about learning "AI magic." It's about writing prompts the way you'd brief a new teammate.

The Solution: Structured, Reusable Prompts

Good Cursor prompts follow a simple formula:

Context + Task + Constraints + Output format

Instead of "create a modal component," you say what framework, styling approach, accessibility needs, and file structure to use.

Below are 15 prompts organized by category. Save them in a notes app, a .cursorrules file, or a personal snippet manager.

Step 1: Setup — Preparing Cursor for React Work

Before using any prompt, give Cursor project-level context. Create a .cursorrules file in your project root:

This is a React 18 + TypeScript project using:
- Vite as the bundler
- Tailwind CSS for styling
- React Query for server state
- Zustand for client state
- React Router v6

Follow these rules:
- Use functional components only
- Prefer named exports
- Always type props with interfaces
- Keep components under 150 lines

This single file dramatically improves every prompt result because Cursor now understands your stack before you ask anything.

Step 2: Configuration — Component Generation Prompts

Prompt 1 — Generate a typed functional component

Create a React functional component called `UserCard` using TypeScript.
Props: name (string), email (string), avatarUrl (string, optional).
Use Tailwind CSS for styling.
Export as a named export.
Include a JSDoc comment above the component.

Prompt 2 — Convert class component to functional

Convert this class component into a functional component using hooks.
Preserve all lifecycle behavior using useEffect.
Keep the same prop types.
Here is the class component: [paste code]

Prompt 3 — Generate a reusable form component

Create a reusable `Input` component with TypeScript that supports:
- label, error message, and helper text props
- forwardRef for form libraries like react-hook-form
- Tailwind styling with an error state (red border)

Step 3: Core Implementation — Hooks, State, and Logic Prompts

Prompt 4 — Custom hook generation

Create a custom hook called `useDebounce` that:
- Accepts a value and delay (ms)
- Returns the debounced value
- Uses TypeScript generics so it works with any type

Example output you should expect:

import { useState, useEffect } from "react";

function useDebounce(value, delay) {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const timer = setTimeout(() => setDebouncedValue(value), delay);
    return () => clearTimeout(timer);
  }, [value, delay]);

  return debouncedValue;
}

export default useDebounce;

Prompt 5 — Fetch data with React Query

Write a React Query hook called `useUsers` that:
- Fetches from GET /api/users
- Uses axios
- Has a 5-minute stale time
- Returns data, isLoading, and error
Follow React Query v5 syntax.

Prompt 6 — Global state with Zustand

Create a Zustand store called `useCartStore` with:
- items array
- addItem, removeItem, clearCart actions
- a computed total price
Type everything with TypeScript.

Prompt 7 — Form validation logic

Create form validation logic for a signup form using react-hook-form and zod.
Fields: email, password (min 8 chars), confirmPassword (must match password).
Return the schema and a usage example.

Step 4: Final Integration — Debugging, Testing, and Refactor Prompts

Prompt 8 — Explain and fix a bug

Here is a React component throwing "Cannot update state on unmounted component".
Explain why this happens and fix it using proper cleanup.
Code: [paste code]

Prompt 9 — Optimize re-renders

Review this component for unnecessary re-renders.
Suggest fixes using React.memo, useCallback, or useMemo where appropriate.
Explain each change briefly.
Code: [paste code]

Prompt 10 — Refactor prop drilling

This component passes props through 4 levels of children.
Refactor it using React Context to avoid prop drilling.
Keep the component API the same for the parent.
Code: [paste code]

Prompt 11 — Write unit tests

Write unit tests for this component using React Testing Library and Vitest.
Cover: default render, click interactions, and conditional rendering.
Do not test implementation details.
Code: [paste code]

Prompt 12 — Accessibility audit

Review this component for accessibility issues.
Check ARIA attributes, keyboard navigation, and color contrast assumptions.
List each issue and provide the fixed code.
Code: [paste code]

Prompt 13 — Convert to Suspense-based data fetching

Refactor this useEffect-based data fetching into a Suspense-compatible pattern using React Query's useSuspenseQuery.
Include the required Suspense boundary and fallback UI.
Code: [paste code]

Prompt 14 — Generate a loading/error/empty state pattern

Create a reusable `<AsyncBoundary>` component that handles loading, error, and empty states for any children.
Accept isLoading, error, and isEmpty as props.
Keep it generic and reusable across the app.

Prompt 15 — Explain code like a senior engineer

Explain this React code as if teaching a mid-level developer.
Focus on why it's written this way, not just what it does.
Point out any anti-patterns.
Code: [paste code]

Common Mistakes Developers Make With Cursor Prompts

Pasting code without context
Cursor guesses your stack. Always mention React version, TypeScript, and libraries.

Asking for "the whole app" in one prompt
Large, vague prompts produce inconsistent code. Break tasks into components, hooks, and logic separately.

Not specifying output format
Without asking for TypeScript, tests, or comments, Cursor defaults to the simplest possible output.

Blindly accepting generated code
AI-generated code can look correct but miss edge cases. Always review before merging.

Best Practices for Using Cursor in React Projects

Keep a .cursorrules file updated as your stack evolves
Save your best prompts in a shared team doc — consistency matters more than cleverness
Ask Cursor to explain, not just generate — this catches bad assumptions early
Use small, single-responsibility prompts instead of one giant request
Always request TypeScript types explicitly if your project uses them

Visual Explanation Section

(For your published article, add these visuals)

Screenshot: .cursorrules file open in Cursor's editor, showing the project context block
Screenshot: Before/after code diff showing a useEffect cleanup fix from Prompt 8
Diagram: A simple flow showing "Prompt → Cursor → Generated Code → Developer Review → Merge"
Screenshot: React Testing Library test output in the terminal after using Prompt 11

Real-World Use Case

These prompts aren't theoretical — they map directly to daily work on production React apps:

SaaS dashboards: Prompt 6 (Zustand store) and Prompt 5 (React Query) are used constantly for billing, user, and subscription state.
Admin panels: Prompt 3 (reusable form inputs) and Prompt 7 (validation) speed up CRUD screen development.
Mobile-first React apps: Prompt 12 (accessibility audit) matters heavily for apps targeting wide user bases.
Large production codebases: Prompt 10 (prop drilling refactor) and Prompt 9 (re-render optimization) are used during scaling and performance passes.

Conclusion

Cursor is only as good as the prompts you give it. Generic requests produce generic, often broken code. Structured prompts — with context, constraints, and clear output expectations — produce code that actually fits your project.

The 15 prompts above cover the real day-to-day work of a React developer: components, hooks, state, testing, debugging, and refactoring.

Save them, adapt them to your stack, and build your own library over time. That library becomes one of the highest-leverage tools in your workflow.

Want to Build React Apps Faster with AI?

Learning React is one thing. Building real-world applications efficiently is another.

That’s why I created The Ultimate React + Cursor Prompt Library (1000+ AI Prompts) a practical collection of AI prompts designed specifically for React developers.

Each prompt is designed to help you get better results from AI coding assistants like Cursor, ChatGPT, and Claude, so you can spend less time figuring out what to ask and more time building.

Instead of staring at a blank Cursor chat wondering what prompt to write, you can start with proven prompts and adapt them to your own projects.

👉 The Ultimate React + Cursor Prompt Library: 1000+ AI Prompts →

I Used Cursor AI to Build React Apps for 30 Days Here's What Actually Made Me Faster

Nabeel Krissane — Fri, 04 Sep 2026 05:55:38 +0000

Introduction

Every developer has felt this pain: you know exactly what component you need to build, but you still spend 20 minutes typing boilerplate, fixing imports, and Googling syntax you've written a hundred times before.

I spent 30 days using Cursor, the AI-powered code editor, to build multiple React apps from scratch a dashboard, a SaaS landing page, and an internal admin tool. My goal was simple: figure out if Cursor actually makes React development faster, or if it's just another overhyped AI coding tool.

In this article, you'll learn exactly what worked, what didn't, and the specific Cursor workflows that cut my React development time by roughly 40%. No hype just real code, real mistakes, and real results.

If you're a React developer wondering whether Cursor is worth adopting into your workflow, this guide will save you the 30 days I spent testing it.

The Problem: Why React Development Feels Slower Than It Should

React itself isn't slow. The process around it is.

Most of the time developers lose isn't spent solving hard logic problems it's spent on repetitive, low-value work:

Writing the same component boilerplate over and over
Setting up props, types, and interfaces manually
Switching between docs, Stack Overflow, and the editor
Debugging small syntax or type errors
Writing repetitive API integration code

The usual "fix" developers reach for is copy-pasting old components and hacking them into shape. This works short-term, but it quietly creates messy, inconsistent codebases.

Autocomplete tools like GitHub Copilot help a little, but they mostly guess line-by-line. They don't understand your entire project structure or your intent which is exactly the gap Cursor tries to close.

Solution Overview: How Cursor Actually Helps

Cursor isn't just "autocomplete with AI." It's a full editor built around AI-assisted coding, with three features that mattered most during my 30-day test:

Codebase-aware chat it reads your project context, not just the open file
Inline edit (Cmd+K) you select code and describe changes in plain English
Multi-file generation it can scaffold components, hooks, and API logic together

The real speed gain doesn't come from Cursor "writing your app for you." It comes from removing the repetitive typing and context-switching that slows React developers down.

Step-by-Step: How I Used Cursor to Build React Apps Faster

Step 1: Setup

I started every project the same way a standard Vite + React + TypeScript setup, since this is the most common stack developers use in 2025.

npm create vite@latest my-app -- --template react-ts
cd my-app
npm install

Once inside Cursor, I opened the project folder directly. Cursor automatically indexes the codebase, which is what allows its chat and inline edits to understand your file structure, types, and existing components.

Step 2: Installation / Configuration

For consistent AI output, configuration matters more than people expect. I added a .cursor/rules file to guide Cursor's suggestions toward my project's conventions.

# .cursor/rules
- Use functional components with TypeScript
- Use Tailwind CSS for styling
- Prefer named exports over default exports
- Keep components under 150 lines; extract logic into hooks

This single step reduced the amount of "cleanup editing" I had to do after every AI-generated component by a noticeable margin.

Step 3: Core Implementation

This is where Cursor actually saved time. Instead of manually writing a data-fetching component, I selected a blank file, opened inline edit (Cmd+K), and described what I needed.

Here's a real example a reusable hook for fetching user data:

// hooks/useUsers.ts
import { useState, useEffect } from "react";

interface User {
  id: number;
  name: string;
  email: string;
}

export function useUsers() {
  const [users, setUsers] = useState<User[]>([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    const fetchUsers = async () => {
      try {
        const response = await fetch("/api/users");
        if (!response.ok) throw new Error("Failed to fetch users");
        const data: User[] = await response.json();
        setUsers(data);
      } catch (err) {
        setError(err instanceof Error ? err.message : "Unknown error");
      } finally {
        setLoading(false);
      }
    };

    fetchUsers();
  }, []);

  return { users, loading, error };
}

Cursor generated this in seconds, correctly typed, following the conventions I'd defined in my rules file. My job shifted from typing to reviewing which is a faster and less error-prone way to work.

Step 4: Final Integration

The last step was wiring the hook into a component:

// components/UserList.tsx
import { useUsers } from "../hooks/useUsers";

export function UserList() {
  const { users, loading, error } = useUsers();

  if (loading) return <p>Loading users...</p>;
  if (error) return <p className="text-red-500">Error: {error}</p>;

  return (
    <ul className="divide-y divide-gray-200">
      {users.map((user) => (
        <li key={user.id} className="py-2">
          <p className="font-medium">{user.name}</p>
          <p className="text-sm text-gray-500">{user.email}</p>
        </li>
      ))}
    </ul>
  );
}

Because Cursor had already seen the useUsers hook during generation, the component's types and imports matched perfectly no manual fixing required.

Common Mistakes Developers Make With AI Coding Tools

1. Blindly accepting generated code
AI tools like Cursor are confident even when wrong. Always read the logic before accepting especially around state management and API error handling.

2. Not giving project context
Without a rules file or clear prompts, Cursor defaults to generic patterns that don't match your codebase style.

3. Using AI for architecture decisions
Cursor is great at implementation, not judgment. Decisions like state management strategy or folder structure should still come from you.

4. Prompting too vaguely
"Build a login form" gives generic results. "Build a login form using React Hook Form, Zod validation, and Tailwind, matching the existing Button component" gives production-ready results.

Best Practices for Using Cursor With React

Write a .cursor/rules file early it's the single biggest lever for consistent output
Keep prompts specific mention libraries, styling approach, and existing components
Use inline edit for small changes, and chat for multi-file features
Review generated code like a PR, not like magic
Break large features into smaller prompts this reduces hallucinated logic
Combine AI generation with TypeScript strict mode to catch mismatches early

Visual Explanation (What to Show Here)

If publishing this on Medium, add these visuals for extra clarity:

Screenshot of the Cursor editor with the inline edit (Cmd+K) prompt box open
Screenshot of the .cursor/rules file next to a generated component
A before/after diagram showing manual coding time vs. Cursor-assisted coding time
A folder structure screenshot showing hooks/, components/, and .cursor/rules

Real-World Use Cases

This workflow isn't just for side projects. The same pattern applies to:

SaaS dashboards repetitive CRUD components and data tables
Admin panels forms, filters, and table views with similar structure
Mobile-responsive marketing sites fast section-by-section scaffolding
Internal tools quick prototypes that still need clean, typed code

Any codebase with repeated component patterns is where Cursor saves the most time because the AI has consistent context to learn from.

Conclusion

After 30 days of building React apps with Cursor, the biggest lesson wasn't that "AI writes better code than developers." It doesn't.

The real win is that Cursor removes repetitive, low-value work boilerplate, typing, context-switching so you spend more time on actual engineering decisions.

The developers who benefit most from Cursor aren't the ones who blindly accept every suggestion. They're the ones who set clear conventions, write specific prompts, and review AI output like any other code.

If you're serious about speeding up your React workflow, the setup matters as much as the tool itself.

Want to Build React Apps Faster with AI?

Learning React is one thing. Building real-world applications efficiently is another.

That’s why I created The Ultimate React + Cursor Prompt Library (1000+ AI Prompts) a practical collection of AI prompts designed specifically for React developers.

Each prompt is designed to help you get better results from AI coding assistants like Cursor, ChatGPT, and Claude, so you can spend less time figuring out what to ask and more time building.

Instead of staring at a blank Cursor chat wondering what prompt to write, you can start with proven prompts and adapt them to your own projects.

👉 The Ultimate React + Cursor Prompt Library: 1000+ AI Prompts →

From Prompt to Product: 12 Flutter + AI Apps You Can Build

Nabeel Krissane — Tue, 25 Aug 2026 08:00:00 +0000

Introduction

Most Flutter developers know how to build clean UIs — but struggle to turn a simple app idea into something powered by real AI features.

You've probably seen dozens of "AI app" tutorials that stop at a single API call and never show you how to structure a real, production-ready Flutter + AI app.

That's the real problem: there's a huge gap between "calling an API" and "building a product."

In this article, you'll learn 12 practical Flutter + AI app ideas you can actually build, along with the architecture, code patterns, and implementation steps for each — so you go from prompt to product, not just prompt to demo.

By the end, you'll have a clear roadmap for building real AI-powered Flutter apps using tools like OpenAI, Gemini, and on-device ML.

The Problem: Why Most "Flutter + AI" Projects Never Ship

Developers usually approach AI integration the wrong way. Here's what typically goes wrong:

They call an AI API directly from the UI layer, with no separation of concerns.
They hardcode API keys in the Flutter app (a serious security risk).
They don't handle streaming responses, so the UI feels frozen.
They skip error handling for rate limits, timeouts, and malformed responses.
They never think about cost control — one runaway loop can burn your API budget.

This is why so many "AI Flutter apps" stay stuck as weekend prototypes instead of becoming real products.

The Solution: A Repeatable Architecture Pattern

Every app below follows the same core architecture, so once you learn it, you can reuse it across all 12 ideas:

UI Layer (Widgets)
   ↓
State Management (Riverpod / Bloc)
   ↓
Repository Layer (abstracts AI provider)
   ↓
API Service Layer (handles requests, keys, retries)
   ↓
Backend Proxy (Node.js / Laravel) — keeps API keys safe
   ↓
AI Provider (OpenAI, Gemini, Claude, etc.)

This pattern keeps your Flutter app clean, secure, and scalable — regardless of which AI provider you use.

Step-by-Step Implementation (Base Setup Used in All 12 Apps)

Step 1: Project Setup

flutter create ai_flutter_app
cd ai_flutter_app
flutter pub add dio flutter_riverpod flutter_dotenv

Step 2: Environment Configuration

Never store API keys in your Flutter code. Use a .env file loaded only on your backend, not the client.

// lib/core/env.dart
class Env {
  static const backendUrl = String.fromEnvironment(
    'BACKEND_URL',
    defaultValue: 'https://your-backend.com/api',
  );
}

Your Flutter app talks to your backend — your backend talks to the AI provider. This keeps your keys safe.

Step 3: Core API Service

// lib/core/services/ai_service.dart
import 'package:dio/dio.dart';

class AIService {
  final Dio _dio = Dio(BaseOptions(
    baseUrl: Env.backendUrl,
    connectTimeout: const Duration(seconds: 15),
  ));

  Future<String> generateText(String prompt) async {
    try {
      final response = await _dio.post('/ai/generate', data: {
        'prompt': prompt,
      });
      return response.data['result'] as String;
    } on DioException catch (e) {
      throw Exception('AI request failed: ${e.message}');
    }
  }
}

Step 4: State Management with Riverpod

// lib/features/chat/chat_provider.dart
final aiServiceProvider = Provider((ref) => AIService());

final chatResponseProvider =
    FutureProvider.family<String, String>((ref, prompt) async {
  final service = ref.read(aiServiceProvider);
  return service.generateText(prompt);
});

This same 4-step pattern is the foundation for every app idea below.

12 Flutter + AI App Ideas You Can Build

1. AI Chat Assistant App

A ChatGPT-style app using streaming responses and conversation history stored locally with Hive or Isar.

2. AI Resume Builder

User inputs their experience → AI generates polished resume content → export as PDF using the pdf package.

3. AI Image Caption Generator

Upload an image → send to a vision model → generate SEO-friendly captions for social media.

4. AI Voice Journal App

Record voice → transcribe with Whisper API → summarize entries using GPT for mood tracking.

5. AI Recipe Generator

User enters ingredients they have → AI suggests recipes → save favorites offline.

6. AI Study Buddy / Flashcard Generator

Paste notes → AI converts them into flashcards → spaced repetition logic built with local storage.

7. AI Code Explainer App

Paste a code snippet → AI explains it line by line — great for junior devs and students.

8. AI Fitness Plan Generator

User inputs goals and equipment → AI generates a weekly workout plan with progress tracking.

9. AI Customer Support Chatbot (SaaS Widget)

Embeddable Flutter Web widget that answers FAQs using a custom knowledge base + RAG.

10. AI Travel Itinerary Planner

User enters destination and days → AI builds a day-by-day itinerary with local suggestions.

11. AI Email/Message Rewriter

Paste rough text → AI rewrites it in different tones (professional, friendly, concise).

12. AI-Powered Admin Dashboard Insights

Flutter Web dashboard where AI summarizes analytics data into plain-English insights for non-technical stakeholders.

Common Mistakes Developers Make

Calling AI APIs directly from Flutter — exposes your API key and lets anyone drain your quota.
No loading/streaming states — makes the app feel broken during generation.
Ignoring token limits — leads to truncated or failed responses on longer prompts.
No caching — repeated identical requests waste money and time.
Skipping error boundaries — a single failed API call crashes the whole flow instead of degrading gracefully.

Best Practices & Tips

Always proxy AI requests through your own backend (Node.js, Laravel, or Firebase Functions).
Use streaming (SSE or chunked responses) for chat-like experiences — it feels dramatically faster.
Cache repeated prompts locally to reduce cost and latency.
Set max token limits per request to control your AI spend.
Use Riverpod or Bloc to keep AI state separate from UI state — makes testing much easier.
Add retry logic with exponential backoff for rate-limited requests.

Visual Explanation Section

(Descriptions only — no images generated here)

Architecture diagram: Show the flow from Flutter UI → Backend Proxy → AI Provider, with arrows and labeled boxes.
Chat app UI mockup: Show a simple chat bubble interface with a streaming "typing" indicator.
Folder structure screenshot: Show lib/core, lib/features, lib/services organized cleanly.
API response flow diagram: Show request → backend validation → AI call → response → UI update.

Real-World Use Case

This exact architecture pattern is used in:

SaaS products — AI-powered chat widgets embedded in customer dashboards.
Mobile productivity apps — journaling, note summarization, resume tools.
Admin panels — turning raw analytics into plain-English summaries for non-technical teams.
EdTech apps — flashcard and study tools used by thousands of students daily.

The pattern scales from a solo indie app to a multi-tenant SaaS product without major rewrites.

Conclusion

Building Flutter + AI apps isn't about calling an API once — it's about architecture, security, and user experience working together.

With the repeatable pattern shown here (UI → State → Repository → Backend Proxy → AI Provider), you can confidently build any of these 12 app ideas — and many more beyond them.

Start small, pick one idea, and ship it end-to-end. That's how you go from prompt to product.

Want to build AI-powered mobile apps with Flutter?

Learning AI integration by building small demos is a great way to understand the basics. But if you want to create real-world applications, you need more than just API calls , you need practical projects, proven architectures, and a clear roadmap.

I created Build AI-Powered Mobile Apps with Flutter: 15 Real Projects to help Flutter developers learn by building real applications.

Inside this guide, you’ll discover how to build AI-powered apps including chat assistants, image generators, voice assistants, AI analyzers, productivity tools, and more.

Each project includes the app idea, features, technology choices, development steps, architecture guidance, and ready-to-use AI coding prompts that help you build faster with tools like ChatGPT, Claude, and Cursor.

Instead of spending weeks figuring out what to build and how to integrate AI, you can follow practical projects and turn ideas into working mobile applications.

👉 Build AI-Powered Mobile Apps with Flutter: 15 Real Projects →

What Can You Actually Build With Flutter + AI in 2026? Here Are 15 Ideas

Nabeel Krissane — Mon, 24 Aug 2026 10:00:40 +0000

Introduction

Every Flutter developer eventually hits the same wall: you know Flutter well, you've heard "AI is the future," but you have no idea what to actually build.

Tutorials show you how to call an API. They rarely show you how to turn Flutter + AI into a real, shippable product.

This matters because in 2026, apps that don't offer any intelligent feature — smart suggestions, chat assistants, image recognition, personalization — already feel outdated to users.

In this article, you'll learn 15 practical Flutter + AI project ideas, complete with real code examples, common mistakes to avoid, and best practices for structuring these features in production apps. By the end, you'll know exactly what to build next.

Why Developers Struggle to Combine Flutter and AI

Most Flutter developers understand widgets, state management, and API calls. AI integration feels different, and that difference causes three common problems:

1. They think AI requires a data science background.
In reality, most Flutter + AI apps just call a cloud API (like OpenAI, Gemini, or a custom backend). No model training required.

2. They don't know where AI logic should live.
Should the AI call happen in the widget? In a service class? In a backend? Without a clear pattern, apps become messy fast.

3. They copy tutorial code that isn't production-ready.
No error handling, no loading states, no separation of concerns — it works once, then breaks in real usage.

The good news: once you understand a simple, repeatable architecture, you can plug AI into almost any Flutter app idea below.

Solution Overview

The pattern used across all 15 ideas below is the same:

Flutter UI captures user input (text, image, voice, or file)
A service class sends that input to an AI API
The response is parsed and displayed in the UI
State management (Provider, Riverpod, or Bloc) handles loading/error/success states

Once you have this pattern down, every idea on this list becomes a variation of the same architecture.

Step-by-Step Implementation (Base Pattern)

Let's build the foundation you'll reuse across every idea in this list: an AI Service Layer in Flutter.

Step 1: Setup

Create a new Flutter project or use an existing one.

flutter create ai_flutter_app
cd ai_flutter_app

Add the required packages:

dependencies:
  flutter:
    sdk: flutter
  http: ^1.2.0
  provider: ^6.1.2
  flutter_dotenv: ^5.1.0

Run:

flutter pub get

Step 2: Configuration

Store your API key safely using flutter_dotenv. Never hardcode API keys.

Create a .env file in the root folder:

AI_API_KEY=your_api_key_here
AI_API_URL=https://api.openai.com/v1/chat/completions

Load it in main.dart:

import 'package:flutter_dotenv/flutter_dotenv.dart';

Future<void> main() async {
  await dotenv.load(fileName: ".env");
  runApp(const MyApp());
}

Step 3: Core Implementation (AI Service Class)

This is the reusable core you'll use in every project idea below.

import 'dart:convert';
import 'package:http/http.dart' as http;
import 'package:flutter_dotenv/flutter_dotenv.dart';

class AIService {
  final String _apiUrl = dotenv.env['AI_API_URL']!;
  final String _apiKey = dotenv.env['AI_API_KEY']!;

  Future<String> getAIResponse(String prompt) async {
    try {
      final response = await http.post(
        Uri.parse(_apiUrl),
        headers: {
          'Content-Type': 'application/json',
          'Authorization': 'Bearer $_apiKey',
        },
        body: jsonEncode({
          "model": "gpt-4o-mini",
          "messages": [
            {"role": "user", "content": prompt}
          ],
        }),
      );

      if (response.statusCode == 200) {
        final data = jsonDecode(response.body);
        return data['choices'][0]['message']['content'];
      } else {
        throw Exception('AI request failed: ${response.statusCode}');
      }
    } catch (e) {
      throw Exception('Error fetching AI response: $e');
    }
  }
}

What this does:

Sends the user's prompt to the AI API
Handles the HTTP request and response parsing
Throws clear errors instead of failing silently

Step 4: Final Integration (Connecting UI to the Service)

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

  @override
  State<ChatScreen> createState() => _ChatScreenState();
}

class _ChatScreenState extends State<ChatScreen> {
  final AIService _aiService = AIService();
  final TextEditingController _controller = TextEditingController();
  String _response = '';
  bool _isLoading = false;

  Future<void> _sendPrompt() async {
    setState(() => _isLoading = true);
    try {
      final result = await _aiService.getAIResponse(_controller.text);
      setState(() => _response = result);
    } catch (e) {
      setState(() => _response = 'Something went wrong. Try again.');
    } finally {
      setState(() => _isLoading = false);
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Flutter AI Demo')),
      body: Padding(
        padding: const EdgeInsets.all(16),
        child: Column(
          children: [
            TextField(
              controller: _controller,
              decoration: const InputDecoration(hintText: 'Ask something...'),
            ),
            const SizedBox(height: 12),
            ElevatedButton(
              onPressed: _isLoading ? null : _sendPrompt,
              child: _isLoading
                  ? const CircularProgressIndicator()
                  : const Text('Ask AI'),
            ),
            const SizedBox(height: 20),
            Text(_response),
          ],
        ),
      ),
    );
  }
}

This gives you a working Flutter + AI chat screen with loading and error states — the base you'll reuse below.

15 Flutter + AI Project Ideas You Can Actually Build

AI Chat Assistant — customer support bot inside your app using the pattern above.
Smart Journaling App — AI summarizes and tags daily entries.
AI Resume Builder — user inputs experience, AI generates formatted resume text.
Image Caption Generator — pair image_picker with a vision API to auto-caption photos.
AI Recipe Generator — user lists ingredients, AI returns recipes.
Voice-to-Task App — speech-to-text input converted into structured to-do items.
AI Study Buddy — students paste notes, AI generates quiz questions.
Smart Expense Categorizer — AI classifies transactions from bank SMS/CSV imports.
AI Code Explainer App — paste code snippets, get plain-English explanations.
Personalized Workout Planner — AI generates plans based on user goals.
AI Email/Message Composer — generates professional replies from bullet points.
Product Description Generator — for e-commerce seller apps.
AI Travel Itinerary Planner — input destination and days, get a full plan.
Mood-Based Music/Content Recommender — combine sentiment analysis with recommendations.
AI-Powered Admin Dashboard Assistant — natural language queries over business data (e.g., "show me last month's top products").

Each of these reuses the same AIService pattern — only the prompt and UI change.

Common Mistakes Developers Make

1. Hardcoding API keys in the codebase.
This exposes your key when the app is decompiled. Always use environment variables or a backend proxy.

2. Calling AI APIs directly from the UI widget.
This tightly couples UI and logic, making testing and reuse painful. Always use a service class.

3. No loading or error states.
AI responses can take 2–5 seconds. Without loading indicators, users think the app froze.

4. Sending unbounded user input.
Long prompts increase cost and latency. Always trim or validate input length.

5. Ignoring rate limits.
Spamming the API during testing can get your key throttled or banned. Add debouncing on user input.

Best Practices and Tips

Use a backend proxy (Node.js, Laravel, or Firebase Functions) between Flutter and the AI API in production. This hides your API key completely.
Cache repeated responses locally to reduce cost and latency.
Stream responses when possible for a better UX (typing effect instead of waiting for the full response).
Use Riverpod or Bloc for state management once your AI features grow past a single screen.
Set timeouts on HTTP requests so the UI doesn't hang indefinitely.
Log failures (not user data) to catch API issues early.

Visual Explanation Section

(Descriptions only — no images generated)

Screenshot 1: Flutter chat screen UI showing a text input field, "Ask AI" button, and a response bubble below it.
Screenshot 2: Folder structure showing lib/services/ai_service.dart, lib/screens/chat_screen.dart, and .env file at the root.
Diagram: A simple flow — User Input → Flutter UI → AI Service → HTTP Request → AI API → JSON Response → Parsed Text → UI Update.

Real-World Use Cases

This exact pattern is used in production apps today:

SaaS tools use it for AI-powered onboarding assistants and support chat.
Mobile productivity apps use it for smart summarization and task generation.
E-commerce apps use AI for product descriptions and personalized recommendations.
Admin dashboards use natural language queries to let non-technical staff pull data without writing SQL.

The architecture doesn't change between these — only the prompt and the UI layer do.

Conclusion

Flutter + AI isn't about building complex machine learning models. It's about wiring a clean service layer to a capable AI API and designing a UI that handles loading, errors, and responses gracefully.

With the base pattern from this article, you can build any of the 15 ideas listed above — and dozens more — without starting from scratch each time.

The key takeaway: master one solid AI service architecture, and every new "AI feature" becomes a small variation, not a new problem.

Want to build AI-powered mobile apps with Flutter?

I created Build AI-Powered Mobile Apps with Flutter: 15 Real Projects to help Flutter developers learn by building real applications.

Inside this guide, you’ll discover how to build AI-powered apps including chat assistants, image generators, voice assistants, AI analyzers, productivity tools, and more.

Instead of spending weeks figuring out what to build and how to integrate AI, you can follow practical projects and turn ideas into working mobile applications.

👉 Build AI-Powered Mobile Apps with Flutter: 15 Real Projects →

I Stopped Asking Cursor to “Fix My Code” Here’s What I Do Instead

Nabeel Krissane — Thu, 20 Aug 2026 06:06:55 +0000

Cursor is one of the most powerful AI coding editors available today. But if you've used it on a real React codebase, you've probably hit this frustrating pattern: you ask for a small change, and Cursor rewrites half your component, breaks your state logic, or introduces bugs that weren't there before.

This isn't bad luck. It's a predictable problem with a predictable fix.

In this article, you'll learn exactly why Cursor keeps breaking your React code, the mistakes most developers make when prompting it, and the practical workflow that keeps your codebase stable while still using AI to move fast.

By the end, you'll have a repeatable system for using Cursor on React projects without babysitting every change.

The Problem: Why Cursor Breaks React Code

Cursor is an LLM working on your codebase, not a developer who understands your architecture. That distinction matters more in React than almost any other framework.

Here's why:

1. React has invisible context (state, props, hooks)
Cursor sees the file you're editing, but it doesn't always fully trace how state flows through parent components, context providers, or custom hooks. When it "fixes" a bug, it can quietly break a dependency it never saw.

2. Large, vague prompts cause large, vague edits
When you ask Cursor to "refactor this component" without scope, it interprets that broadly. It may rename variables, restructure JSX, or change hook order — all in one pass.

3. It doesn't know your conventions
Cursor doesn't know your team uses Zustand instead of Redux, or that you never use useEffect for derived state. Without guardrails, it defaults to generic React patterns that clash with your codebase.

4. Multi-file changes are riskier than they look
React components are rarely isolated. A prop type change in one file can silently break three others. Cursor doesn't always catch the ripple effect.

The common developer mistake? Treating Cursor like a senior engineer who "just knows" the codebase, instead of treating it like a fast junior dev who needs clear instructions and boundaries.

The Solution Overview

The fix isn't to stop using Cursor. It's to change how you prompt it and how you review its output.

The core idea:

Scope every request tightly
Give Cursor the right context before it edits
Review diffs like a code review, not a rubber stamp
Use rules files to enforce your project's conventions

Let's implement this step by step.

Step-by-Step Implementation

Step 1: Setup — Give Cursor Project Context

Before writing any prompts, set up a .cursorrules file at your project root. This tells Cursor how your React project works.

# .cursorrules

- This is a React + TypeScript project using functional components only.
- State management: Zustand (no Redux, no Context API for global state).
- Styling: Tailwind CSS only. No inline styles, no CSS modules.
- Do not modify files outside the current task scope.
- Always preserve existing prop types unless explicitly asked to change them.
- Prefer small, isolated changes over large refactors.

This single file eliminates most of Cursor's "guessing" behavior.

Step 2: Configuration — Scope Cursor to Specific Files

Instead of letting Cursor search your whole repo, manually attach only the relevant files using @filename references.

@Button.tsx @useCartStore.ts

Update the Button component to show a loading spinner 
when `isLoading` is true. Do not change existing props.

This prevents Cursor from touching unrelated files it "thinks" are connected.

Step 3: Core Implementation — Write Scoped, Specific Prompts

Vague prompts produce vague (and dangerous) edits. Compare these two:

❌ Risky prompt:

Refactor this component to be cleaner.

✅ Safe prompt:

In CartSummary.tsx, extract the total price calculation 
into a separate function called `calculateTotal`. 
Do not change any JSX or component structure.

The second prompt gives Cursor a clear boundary. It knows exactly what to touch and what to leave alone.

Here's a real example of a safe, scoped fix:

// Before
function CartSummary({ items }: { items: CartItem[] }) {
  const total = items.reduce((sum, item) => sum + item.price * item.qty, 0);

  return <div className="text-lg font-semibold">Total: ${total}</div>;
}

// After (Cursor's scoped edit)
function calculateTotal(items: CartItem[]): number {
  return items.reduce((sum, item) => sum + item.price * item.qty, 0);
}

function CartSummary({ items }: { items: CartItem[] }) {
  const total = calculateTotal(items);

  return <div className="text-lg font-semibold">Total: ${total}</div>;
}

Notice nothing else changed — no renamed props, no restructured JSX.

Step 4: Final Integration — Review Before Accepting

Never click "Accept All" on a multi-file change without reviewing the diff.

A simple review checklist:

Did any prop types change unexpectedly?
Did hook order change?
Were any imports removed that are still used elsewhere?
Did styling classes get altered outside the requested scope?

Cursor's diff view makes this fast — use it every time, not just for big changes.

Common Mistakes Developers Make

Mistake 1: Asking for multiple things in one prompt
"Fix the bug and also clean up the styling and rename this" — Cursor tries to do all three at once, increasing risk.

Mistake 2: Not attaching the right files
Without @filename context, Cursor guesses which files matter, and guesses wrong more often than expected.

Mistake 3: Skipping the .cursorrules file
This is the single most skipped setup step, and it's the reason most "Cursor broke my code" complaints happen.

Mistake 4: Accepting changes without reading the diff
AI-generated code looks correct at a glance. Bugs often hide in logic, not syntax.

Best Practices and Tips

Keep prompts scoped to one component or one function at a time
Use .cursorrules to lock in architecture decisions
Commit before big AI-assisted refactors, so you can roll back instantly
Use TypeScript — it catches many AI-introduced errors automatically
For complex state logic, write the logic yourself and let Cursor handle boilerplate instead

Performance tip: Cursor tends to over-add useEffect calls. Always double-check if the logic could be derived during render instead.

Visual Explanation Section

(Add screenshots here for Medium)

Screenshot 1: Show the .cursorrules file open in the editor sidebar
Screenshot 2: Show Cursor's diff view with an accepted vs. rejected change highlighted
Screenshot 3: Show a folder structure with .cursorrules at the project root
Diagram: A simple flow showing "Vague Prompt → Broad Edit → Bugs" vs "Scoped Prompt → Isolated Edit → Stable Code"

Real-World Use Case

This workflow matters most in:

SaaS dashboards, where shared components (buttons, tables, modals) are reused across dozens of pages — one bad AI edit can break multiple screens.
Production e-commerce apps, where state management bugs directly affect checkout flows.
Admin panels, where role-based UI logic is easy for AI to misinterpret without proper context.

Teams that adopt .cursorrules and scoped prompting report far fewer regressions from AI-assisted changes, especially in shared component libraries.

Conclusion

Cursor doesn't break React code because it's a bad tool — it breaks React code when it's used without context, scope, or review.

To recap:

Set up a .cursorrules file to lock in your project's conventions
Attach only relevant files to each prompt
Write scoped, specific prompts instead of vague ones
Always review diffs before accepting changes

Follow this workflow, and Cursor becomes a genuine productivity boost instead of a source of new bugs.

Want to get better results from Cursor when building React apps?

AI coding assistants can make React development dramatically faster. But the quality of the result often depends on how you communicate with the AI.

A simple prompt like “fix this bug” or “refactor this component” can produce inconsistent results. The better approach is to give Cursor the right context, constraints, development steps, and validation instructions.

That’s why I created The Ultimate React + Cursor Prompt Library — 1000+ AI Prompts: a practical AI-powered development toolkit designed for real-world React projects.

Inside the library, you’ll find 1,000+ practical prompts covering the entire React development workflow, including building UI components, integrating APIs, authentication, state management, debugging, refactoring, performance optimization, testing, deployment, architecture, and more.

The prompts are designed to help Cursor:

Understand your existing codebase before making changes
Find root causes instead of applying random fixes
Make targeted changes without unnecessary rewrites
Preserve existing functionality
Refactor code safely
Improve performance
Write and improve tests
Validate changes before you ship

Instead of spending time figuring out how to phrase every request to your AI coding assistant, you can start with a structured prompt designed for the specific development problem you’re trying to solve.

Better prompts → Better React code.

👉 Get The Ultimate React + Cursor Prompt Library →

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!