Write a One-Page Brief Before You Prompt
What it is
A short, plain-language brief — a paragraph or a page — written before the first line of code, saying what the app does, who uses it, and what its core screens or actions are. It becomes both the instruction you hand the AI and the yardstick you measure its output against.
Why it works
Without a fixed target, every prompt drifts and the AI cheerfully builds something plausible that isn't what you wanted. A brief anchors the whole build: the model has the full picture instead of guessing from one instruction at a time, and you can tell whether each piece serves the goal or wanders off it. A little clarity up front prevents a lot of rework later.
When to use it
At the start of any project bigger than a quick experiment. Ten minutes writing the brief pays for itself many times over across the build.
When not to use it
For a tiny throwaway or a single script, a full brief is overkill — a one-line description is enough. The brief scales with the ambition of the project.
Prompt
Here's my app idea: <a few sentences>. Help me turn it into a one-page brief before we build: the core purpose in one line, who the users are, the 3–5 key screens or actions, and what's explicitly out of scope for the first version. Keep it tight — we'll build against this.Example
Instead of prompting 'build me a booking app' and getting a sprawling, wrong result, a maker writes a half-page brief — 'clients pick a time slot, get a confirmation email; I see today's bookings; no payments in v1' — and every subsequent prompt is measured against it, keeping the build on track.
Advanced version
Keep the brief in the project (a README or a notes file the AI can read) and update it as scope changes, so the model always builds against the current target. Explicitly listing what's out of scope for the first version is often more valuable than the in-scope list — it stops the AI gold-plating.
Common mistakes
- Diving straight into prompts with only a vague idea, then watching the app drift feature by feature.
- Writing an enormous spec for a first version instead of the smallest brief that captures the core.
- Never saying what's out of scope, so the build sprawls into half-finished extras.