Why the classic specification fails
The traditional specification has a structural flaw: it describes the imagined tool rather than the real business. It lists screens, buttons and requirements (“the system shall allow…”) before establishing the only thing that matters: what data exists, how it links, who keeps it alive.
Every IT project knows the result: the delivered tool conforms to the document and misfits the field — because the document itself was fiction. And writing it cost weeks that produced no software.
The one-page structure: four blocks
A management application is fully described with four blocks. It's the structure experienced designers use — and exactly what Blueprint Maker extracts from your description to build the application plan.
- THE THINGS (entities): what you track — clients, projects, items, work orders. A list of 3 to 8 nouns, each with its key information (fields).
- THE LINKS (relations): how things attach — “a project belongs to a client”, “a work order concerns a piece of equipment”. One sentence per link.
- THE STATES (statuses): your objects' life cycle — “quote, signed, in progress, done, invoiced”. Your own words, in real order.
- THE NUMBERS (indicators): what you want every morning — amounts to invoice, late files, stock below threshold. Three to six indicators.
Complete example: one page that suffices
“Fence-installation company, 4 people. THINGS: clients (name, address, phone), projects (address, fence type, length, quote amount, planned date), work sessions (date, hours, team), materials (reference, stock). LINKS: a project belongs to a client; a session happens on a project; materials are consumed per project. STATES of a project: quote sent, signed, scheduled, in progress, done, invoiced, settled. NUMBERS: active projects, metres installed this month, amount to invoice, materials below threshold.”
That page contains everything needed to build the application — by a developer or a generator. What it doesn't contain is just as telling: no screen descriptions, no technical choices, no numbered requirements. Screens FOLLOW from the structure.
The three writing traps
Trap 1 — describing the current tool: “I want columns A to R of my spreadsheet”. The spreadsheet is a source of information, not a target: extract the things and links, not the layout.
Trap 2 — the greedy scope: wanting to cover compliant invoicing, payroll, accounting. Those regulated domains have their tools; your application stops where they start and excels at your operational tracking.
Trap 3 — edge cases first: “what if a client is also a supplier?”. Describe the normal flow that covers 90% of days first; edge cases are added later, on a sound structure.
From page to application: two paths
Classic path: the page briefs a developer or agency — it drastically reduces misunderstanding risk and billed scoping time.
Direct path: the page IS the prompt. Given to Blueprint Maker, it becomes a structured application plan — entities, relations, statuses, indicators — which you validate before generation. The application arrives deployed, with demo data: your specification is verified on real screens, not in acceptance meetings. And if a developer steps in later, they start from the generated code (ZIP export, GitHub push) instead of a blank page.
The template to copy
Take these four lines and fill them with your words: “My business: … THINGS tracked (with key information): … LINKS between them: … STATES they go through: … NUMBERS to see every morning: …” Ten lines are enough; the Discovery plan (€0) lets you immediately test what your page produces as an application.