The One-Page App Spec: The Document That Separates Shipped Apps from the Graveyard

The builders who ship plan before they prompt. Three independent creators, watched by millions, converge on the same pre-build artefact: a plain-language document that tells the AI exactly what to make and what not to make. Sherriff Andrew, a non-technical product manager, opens his deployment tutorial with the line 'vibe coding is only as good as your requirements' (Sherriff Andrew, 2026), and writes the requirements document before touching a tool. Connor, who vibe coded a $20K per month mobile app in 14 days (Starter Story, 2026), does the same with his data: 'The next step is you're going to want to design your data structures. This is very important specifically for vibe coding... so it doesn't have to make any guesses on what you're trying to make.' It took him 6 to 8 months and a failed first app to learn that habit. Brian Jenney, who watched an AI-first startup nearly collapse under its own generated code, puts a price on skipping the document: 'A day of planning can save a week of coding... Slow down the planning, speed up the execution. Think deeply so you can code quickly, write docs so you don't waste tokens' (Brian Jenney, Parsity, 2026). The token point is literal money. Every wrong guess is a round of paid tokens spent on the wrong code, then more tokens on the apology, the fix, and the fix of the fix. It helps explain why 46% of developers distrust the accuracy of AI coding tools even while using them daily (Stack Overflow Developer Survey, 2025). The distrust is not really about the model. It is about the brief.

A one-page app spec answers seven questions in plain English: what the app is, who uses it, which screens exist, what data is saved, what the AI feature does, what done looks like, and what is out of scope. Write it anywhere you like: a doc, a note, a text file. Keep it to one page, because longer specs rot and shorter ones leave gaps. Here is the whole template. 1. App name and one-sentence purpose. One sentence that starts with a verb: 'Prospect Pilot writes follow-up messages for busy agents.' If you cannot say it in one sentence, the app is two apps. 2. Who uses it and the one thing they do. Name one person and one job: 'A solo real estate agent writes a follow-up after an inspection.' Multi-user ambitions go in the out-of-scope list. 3. The 3 to 5 screens or pages. Name each screen and add one line on what it shows: Login, New Message, Results, History, Settings. Five screens is plenty for version one. 4. The data you save, field by field, in plain words. Not a database schema, just the fields: prospect name, role, company, notes, the generated message, the date. This one section kills more guesses than any other, because the AI no longer has to invent your database.

The last three parts of the spec do the heavy lifting: they define the AI feature with a real example, set a finish line you can test, and list everything the app will not do yet. 5. The AI feature: input, output, and one example. Write what goes in, what comes out, and paste one real example of a good output directly into the spec. The example is the part most people skip, and it is the part the AI imitates most closely. 6. What done looks like. One sentence you can test: 'A user can sign up, generate three messages, copy one, and find it in their history next week.' If you cannot test it, it is not done, it is a wish. 7. What is explicitly out of scope. The things you will not build yet: sending messages, team accounts, CRM sync. This list is the most valuable part of the page, because it stops the AI helpfully building extras you never wanted and then defending them. The discipline matters more than the format. 42% of startups fail because they build something nobody wants (CB Insights, 2024), and a vague spec is how you build the wrong thing with extra steps. One page forces the decisions to happen before the tokens get spent.

Here is the full template filled in for a real build: an AI outreach tool that turns prospect details into personalised email and LinkedIn messages, with a saved history of everything it writes. - App name and purpose: Prospect Pilot. Writes a personalised first-touch email and LinkedIn message from a prospect's details. - Users: a solo founder doing their own sales. The one thing they do: paste in prospect details, get two ready-to-send messages. - Screens: Login, New Message (the form), Results (both messages with copy buttons), History (past messages, searchable), Settings (tone defaults). - Data saved: prospect name, role, company, website notes, tone choice, the two generated messages, created date. - AI feature: input is the prospect details plus a tone choice; output is one email under 120 words and one LinkedIn message under 60 words. Example output: 'Saw your team just opened a second depot in Dandenong, congrats. We help wholesalers cut quote turnaround from days to minutes...' - Done: a new user can sign up, generate messages, copy them, and find them again a week later. - Out of scope: actually sending the messages, follow-up sequences, team accounts, CRM integration. Notice there is not one technical word in it. No frameworks, no schema language, no jargon, and yet the AI now has almost nothing left to guess: the screens are named, the fields are named, and the AI feature has a concrete example to imitate. Development with AI coding assistants runs 3 to 10 times faster when the task is well defined (McKinsey, 2025), and this is what well defined looks like on one page.

Paste the whole spec into Cursor, Lovable, v0, or Bolt as your very first message, before any code exists, then ask the AI to repeat the plan back to you before it writes a line. 1. Paste the spec as message one. Do not warm up with 'hi, I want to build an app.' The spec is the warmup. 2. Ask the AI to restate the plan and list its assumptions. Anything it gets wrong is a gap in your spec. Fix the spec, not just the chat. 3. Build one screen at a time, in the order the spec lists them, and test each before moving on. 4. When you change your mind, change the spec first, then prompt. The spec stays the single source of truth for the whole build. This habit scales. Cursor passed 7 million monthly active users in early 2026 (Cursor Series D disclosure, 2026), and the builders getting real value from it treat the prompt as a contract, not a conversation starter. The Coding Sloth reached the same conclusion after more than 500 hours of AI-assisted coding (The Coding Sloth, 2026): specificity is the skill, and a spec is specificity written down. If you would rather write yours with a room full of people doing the same thing, that is exactly week one of buildAcademy, our Melbourne programme. You bring your idea, and across the first week you plan the build, scope the database, and design the AI prompt. You leave with your one-page spec and your first screen built. Details are at 13labs.au/buildacademy.

How long should an app spec be for AI coding tools? One page is enough for almost every first version. If you can answer the seven questions (purpose, user, screens, data, AI feature, done, out of scope) in plain English, the AI has everything it needs. A longer document usually means you are designing version two before version one exists. Do I need technical knowledge to write an app spec? No. The template is deliberately non-technical: you name fields in plain words, like 'the customer's email address', rather than designing a schema, and the AI handles the translation. 63% of vibe coding platform users identify as non-developers (Platform usage data, 2025), and a clear brief matters far more than technical vocabulary. Can I use the same spec in Cursor, Lovable, v0, and Bolt? Yes. The spec is tool-agnostic because it describes what to build, not how to build it. Paste it as the first message in any of them. Each tool will ask different follow-up questions; add those answers to the spec once and reuse it everywhere. What happens if I skip the spec and just start prompting? You get guesses, and guesses compound. In The Coding Sloth's three-level experiment, the average-person prompt produced errors, zero styling, and code that would not run (The Coding Sloth, 2026). There is a hidden cost too: 45% of AI-generated code samples fail basic security tests (Veracode, 2025), so unguided output can be broken in ways you cannot see. Should I update the spec as the build changes? Yes, treat it as a living document, but change it deliberately. When a feature idea appears mid-build, add it to the spec first, or park it in the out-of-scope list, and then prompt. The spec-first habit is what stops a one-page plan turning into a 40-message argument with the AI.