Back to course overview
Module 2Idea to spec 14 min

The spec & data model, written with AI

A one-page spec the assistant can build from, the data model as the app's skeleton (two tables, chosen carefully), and the adversarial passes that catch gaps while they're free.

A spec is a letter to your builder — and your builder is an AI, which changes the writing: vagueness that a human contractor would query, an assistant will cheerfully improvise. The one-page spec has four sections, and the assistant helps write all of them:

  • The loop, in sentences: 'Messages arrive in an inbox list, newest first, unread bold. Clicking opens the thread. The user writes or AI-drafts a reply, edits it, marks it sent. The message moves to Replied; the user marks it Done when it's truly finished.' Concrete nouns, present tense, no 'etc.'
  • The screens (three for v1): Inbox (list + status filter), Thread (message, history, reply box, the AI buttons), Settings-lite (the user's reply tone preference and API key — Module 5 explains why it lives server-side). Sketch each as a wireframe — boxes and labels, ugly on purpose; the assistant can generate wireframe descriptions you correct, which is faster than starting from blank.
  • The data model — the decision that outlives every screen: messages (id, sender_name, sender_email, subject, body, status: new/replied/done, received_at) and replies (id, message_id → which message, body, was_ai_drafted, sent_at). Two tables, one relationship (a message has many replies). Everything on the screens must trace to a column; every column must appear on a screen — run that check both ways and you'll catch half your gaps right here.
  • The not-list: the cut list's greatest hits, stated in the spec so the assistant stops helpfully suggesting them: 'No auth in v1 (single user). No email sending (copy-to-clipboard). No pagination until it hurts.'

The adversarial passes (borrowed from the analyst's toolkit)

Before building from the spec, attack it — the same passes the BA course runs on requirements, aimed at your own work: the ambiguity hunt ('read this spec as a literal-minded builder: list everything underspecified' — what happens to empty states? what does 'newest' mean when two arrive together? can a Done message reopen?), the edge-case sweep ('15 edge cases this spec ignores' — the 4,000-word message, the emoji-only message, the reply to a deleted message), and the walking-skeleton check ('what's the minimum slice of this spec that works end to end?' — that slice is Module 3-4's build order). Twenty minutes of passes; each catch is an hour of rework refunded.

The spec is a living document with a short leash

You'll amend the spec as building teaches you — that's healthy. The leash: amendments are written (edit the spec, tell the assistant), and anything that grows scope goes through one question — 'does the loop need this to work?' No: cut list. Yes: swap something out. The spec that silently drifts becomes a spec nobody's following, including you.