Creating AI project briefs

You can — for a landing page or a weekend prototype. For anything with users, a database, auth, and billing, one prompt runs out of context fast. AI tools build exactly what the current prompt says, so on prompt #7 they cheerfully overwrite what prompt #3 established. A brief keeps every screen, table, and rule in one place so the next prompt has real ground to stand on.

A prompt is one instruction ("build me a signup form"). A brief is the full spec the prompt draws from — the problem you're solving, the users, every screen, the database schema, security rules, auth flow, billing, and the order you build things in. A real SaaS build is roughly 15 prompts. A brief is what makes those 15 prompts consistent.

Slower on day one, faster by day three. Most re-work on AI builds isn't bugs — it's the tool building something subtly different from what you meant, then you unwinding it. A tight brief up front removes the "wait, that's not what I wanted" loop.

At minimum: the problem and target user, V1 feature scope (with what's explicitly out), each screen and its states, the database schema, auth method, security/RLS rules, billing model, external integrations (email, payments, analytics), and the build order. BriefKit generates 14 files covering all of this.

Detailed enough that an AI tool building screen 8 knows what happened on screen 2. Vague briefs ("users can manage their team") produce vague builds. Concrete briefs ("an owner can invite up to 5 members by email; invited users land on /accept-invite; RLS restricts team_members to members of the same org") produce concrete builds.

Yes, at least the big choices — frontend framework, database, auth provider, payments. AI tools will pick defaults if you don't, and those defaults often clash with what you'll add later (e.g. an auth library that doesn't play with the payments provider you pick in week 3).

In one sentence: who has the problem, what they do today, and why that's painful. "Freelance designers track invoices in spreadsheets and forget to chase late payments" beats "invoicing is broken." The sharper the sentence, the sharper every decision downstream.

Pick one specific person — role, company size, what tools they already use, what they'd stop doing to use yours. "Solo consultants billing 3–10 clients a month who currently use Google Docs" is buildable. "Small businesses" is not.

One measurable outcome you'd be happy with 30 days after launch — e.g. "20 users have created a paid invoice." Not revenue targets, not growth curves. Success at V1 is proof the core loop works.

Only the ones required for one user to complete the core loop end-to-end once. If your app is invoicing, V1 is: sign up → add a client → send an invoice → mark it paid. Not: teams, recurring invoices, multi-currency, custom templates. Those are v1.1+.

Keep an explicit "not in V1" list next to your feature list. Every time you catch yourself adding "and also…", it goes on the not-in-V1 list instead. BriefKit's triage step forces this: features get locked green (in), amber (later), or red (cut).

If it needs its own database tables, its own permissions model, or a third-party integration you haven't touched yet — it's a v2. V1 should reuse the same 4–6 tables and the same auth model everywhere.

All of it, for V1. Tables, columns, types, foreign keys, and which columns are user-scoped. AI tools will happily invent a users table on prompt #3 and a separate profiles table on prompt #9 if you don't tell them there's one already.

Yes. "Users can only see their own data" is a security rule, not a feature — but if you don't spec it, the AI tool will build tables with no policies and every user's data will be readable by every other user. Write the rules per table in the brief.

List them explicitly, including which events trigger which integration (e.g. "on invoice.paid webhook, send receipt via Resend"). This is where AI builds silently drift — the tool wires Stripe but forgets the webhook handler, or sends email from a test address that never leaves the sandbox.

Break each feature into: the screen(s) it touches, the tables it reads/writes, the states (empty, loading, error, success), and the exact copy for buttons and empty states. A prompt built from that spec produces working code. A prompt built from "add a dashboard" produces a guessing game.

Auth → database schema → core create/read flow → the rest of the CRUD → billing → polish. Never billing before auth, never polish before the core loop works. BriefKit outputs a build order file for exactly this reason.

Yes — plain markdown, one file per concern, no images embedded. AI tools read markdown natively and get confused by PDFs and Notion exports. Keep files under ~500 lines each so the tool can hold one in context per prompt.

Talk to 5 potential users first. If you can't describe the problem in their words, the brief will be fiction. Validation doesn't mean surveys — it means one real person saying "yes, I'd pay for that today."

One brief, then one prompt per feature, in the build order above. Don't paste the whole brief into a single prompt — feed the relevant file for each step. Reset context between major features so the tool isn't dragging half-built ideas forward.

Read it back and ask: could a stranger build V1 from this without asking me a single question? If yes, ship it. If no, the gaps are exactly where your AI tool will improvise — and that's where the re-work comes from.