Spec-driven development means the specification comes first and the code is derived from it — not the other way around. The written, reviewed description of roles, requirements, screens and data is the source of truth; prototypes, diagrams and generated code are downstream artifacts that must agree with it.
The alternative, and its cost
Prompt-to-app builders take the opposite bet: type an idea, get a running prototype, iterate by prompting. That is genuinely fast for the first demo. The cost arrives later — the application's actual architecture (who can do what, which data lives where, how the pieces relate) exists only implicitly, scattered across the accumulated prompts. Nobody reviewed it, because nobody could see it.
Spec-driven development spends its effort where change is cheapest. A wrong role on a diagram is a thirty-second fix; the same mistake discovered in a live prototype is an excavation.
What it looks like in practice
On Erlyc, the specification is not a document you are asked to write — it is the output of a review loop:
- Discovery boards expand your plain-language idea into structured elements: brief, needs and data, solution shape, operating model, spec map. You react and refine; the platform redrafts.
- Locking the boards produces the full specification, scored by a critic and versioned on every revision, with the screen map attached.
- Everything downstream is derived: entity model, database schema, Eloquent models, user journeys, and finally the generated Laravel codebase. When the spec changes, the derivations follow.
The result reads the same to a business analyst and a developer — which is the point: both can veto a mistake before it costs anything.
When prototype-first is fine
If you are exploring what an idea even is — a landing page, a throwaway demo, a UI sketch to react to — prototype-first tools are the right instrument. Spec-driven development earns its keep the moment the application has roles, rules and data that must be right, and more than one person who needs to agree on them.