Hello Jonsson,
Thank you for sharing both the conceptual article and the practical example with the kitchen timer. The second post in particular makes the workflow much clearer.
I understand the core idea: move away from “vibe coding” and toward specification-driven development, so that AI assistants generate consistent, traceable code based on explicit intent.
The folder structure (project.md, proposal.md, tasks.md, spec.md, archive, etc.) is well thought out, especially for teams working in modern web stacks.
That said, I have a question regarding practical relevance.
The kitchen timer example is simple and easy to understand, but it does not involve:
database interaction business rules validations legacy constraints or integration into an existing monolithic system
Many of us here work on classic business applications — often monolithic, sometimes DBF-based, sometimes not microservice-oriented, sometimes with only one or two developers involved.
Do you believe OpenSpec really adds value in such environments?
It would be very helpful if you could share a slightly more realistic business example, for instance: a small CRUD module with database access some non-trivial business logic maybe an API endpoint including the actual proposal, tasks, and the prompt used for /openspec-apply
That would make it easier to evaluate where OpenSpec truly shines — especially compared to structured but less formal AI-assisted workflows.
I’m genuinely interested in understanding whether this is mainly an enterprise / multi-team solution, or whether it can also benefit smaller, more traditional development setups.
Best regards, Otto
