A good application specification answers one question completely: what are we building, for whom, and what must it do? Written well, it is the cheapest artifact a project will ever produce — every mistake caught in it costs minutes instead of sprints.
What a complete specification contains
Whatever tool or template you use, a specification that can actually drive development covers:
- Purpose and scope — the problem, the users, and what is explicitly out of scope.
- Roles and permissions — every kind of user, and what each may see and do. This is the section most often skipped, and the most expensive to retrofit.
- Functional requirements — what the system does, stated so that each requirement can be checked off or failed.
- Screens and flows — the surfaces users touch and how they move between them.
- Data model — the entities the application manages, their attributes, and their relationships.
- User journeys — how each persona actually gets their work done, including the alternate and error paths.
Writing it with AI: the loop that keeps it honest
AI is very good at drafting a specification and very bad at knowing whether the draft is true. The workable division of labour is a loop: the AI drafts, you review and react, the AI redrafts — and nothing advances without your say.
On Erlyc that loop is the product:
- Describe the idea in plain language when creating the project — two or three honest paragraphs beat a page of buzzwords. Attach documents if you have them.
- Work the five discovery boards. Each proposed element is there to be accepted, corrected or rejected; the boards are where scope arguments should happen.
- Lock and generate. The full specification is drafted from the boards, scored by a critic, and versioned on every revision. The screen map and user journeys are generated alongside it.
- Read it like a reviewer, not an author. Check the roles table first, then walk one journey end to end. If something reads wrong, refine the boards and regenerate rather than hand-editing the symptom.
- Hand it over. Download it as Markdown, HTML or PDF — or continue straight into Architecture & Code, where the same specification drives the generated application.
Common pitfalls
- Vague input, confident output. An AI will happily elaborate a foggy idea into a crisp-looking document. The crispness is typographic. Fix the input.
- Skipping the roles section because "it's obvious". It never is, and every later artifact inherits the omission.
- Over-specifying the UI — pixel decisions belong to design; the specification owes flows and rules, not colours.
- Treating the first version as final. A specification that was never revised was never really reviewed.
A short checklist
Before calling a specification done: every role can be named; every requirement can fail a test; every screen has a way in; every entity has an owner; one full journey has been walked end to end without hand-waving. If all five hold, you know your app before it is built.