From Idea to Spec

Most first projects don't fail because the AI wrote bad code. They fail because nobody decided what to build before the building started.

"An app for tracking workouts" sounds like a plan. It isn't. It's a direction. The moment you ask AI to build it, the model has to invent a hundred decisions you never made — and it will invent them differently every time you ask.

A spec is how you make those decisions on purpose. It's not a corporate document. For a solo builder it fits on one page.

Why "just build it" goes wrong

When your prompt is vague, the AI fills the gaps with averages. Average screens, average fields, average flows. You get something that technically runs but feels like nobody's product.

Worse: every follow-up prompt drifts. You add a feature, the AI re-guesses the parts you never pinned down, and slowly the project turns into a pile of half-decisions that don't fit together.

A spec stops the drift. Once the core is written down, every prompt builds on top of the same foundation instead of rebuilding it.

The one-page spec

You don't need a methodology. You need answers to five questions.

1. Who is it for — and what do they do today?

Not "everyone." One person, doing one thing, in a way that annoys them.

A freelance designer who tracks invoices in a Notes app and forgets who owes them money.

If you can name the person and their current bad workaround, you have a product. If you can't, you have a feature looking for a home.

2. What is the one job the product does?

The single sentence a user would say to a friend:

"It tells me which invoices are overdue and lets me nudge the client in one tap."

One job. Everything else is later.

3. What does the user see on screen one?

Describe the first screen in plain words. What's the first thing they look at, and what's the first thing they can do?

If you can't describe screen one, the AI definitely can't.

4. What data do you store?

List the things your app remembers. For the invoice app:

• An invoice: client name, amount, due date, paid/unpaid
• A client: name, email

That's it. This list becomes your database later — you've already done the hard part by naming it.

5. What is explicitly NOT in version one?

This is the most important question and the one beginners skip. Write down what you're not building yet:

• No team accounts
• No payment processing
• No mobile app — web only

Cutting scope on paper is free. Cutting it after the AI built it is painful.

Turn the spec into prompts

Now the spec writes your prompts for you. Instead of "build an invoice app," you go step by step:

We're building a web app for freelancers to track invoices.
Data model: an Invoice has client_name, amount, due_date,
and a paid boolean. Start by creating this data structure
and a screen that lists all invoices, newest first.

Each later prompt references the same spec, so the AI never has to re-guess the foundation.

The spec is a draft, not a contract

You will change it. You'll discover screen one is wrong, or the real job is something else. That's fine — the point of writing it down isn't to be right on day one. It's to make your changes deliberate instead of accidental.

Spend thirty minutes on the spec. It's the cheapest half hour in the whole project, and it's the difference between building a product and prompting your way into a mess.