Spec Kit on a real full-stack project: how 17 sprints took a habit tracker to production

Spec-Driven Development has been stretched beyond a one-evening demo to a full-stack release. The LifeSync case study covers 17 sprints of building a habit and goal tracker, two separate repositories, hundreds of tests and a production launch. Its main conclusion: on a large project, SDD is useful not for the speed of code generation but because it keeps the project manageable when backend, frontend and infrastructure start pulling it in different directions.

The example is a B2C service for habits and goals. The backend is built on Spring Boot 3.5 and Java 21, organized as hexagonal architecture across six Maven modules, and uses jOOQ instead of JPA, Kafka for event logic, JWT RS256 and OpenAPI 3.1 as the main API contract. The frontend is built on React 19, TypeScript 5.9, Vite 8, TanStack React Query, Zustand and shadcn/ui with Tailwind CSS.

Over 17 sprints the project grew to 251 tests on the server side and 77 on the client, gained 19 Liquibase migrations and went to production: the backend is deployed on Railway, the frontend on Vercel.

The central idea of the case is that scale demanded a different discipline for working with AI. In a small project, one thinking chat and one execution environment were enough. For full-stack work, the author arrived at a setup of three chats: one context for the backend, one for the frontend, and one for coordinating shared decisions that affect both repositories, such as deployment, cross-cutting features, API changes and retrospectives.

This is complemented by two separate constitution files. The backend document grew from a template to 437 lines over time and absorbed rules on migrations, commits, style and OpenAPI. The frontend constitution turned out noticeably more compact, at 137 lines, because the stack and patterns there were more tightly defined from the start.

The author puts particular emphasis on the speckit.analyze command, which they use as a mandatory feedback loop after every sprint. It does not replace tests and does not pretend to be a linter; it cross-checks spec.

md, plan.md, tasks.md and the actual implementation against each other.

According to the author, this kind of analysis caught a critical problem in the backend Kafka sprint: in several use cases, events were published inside a transaction without a protective try-catch. The bug never showed up in the test environment because Kafka in containers was always available, but in a real outage it could have rolled back already-saved data and left the system in an inconsistent state. After the analysis, protection was added to the code, the retry logic was refined and the integration checks were expanded.

Another key pillar is the API-first approach as a contract between the two repositories. The project has a dedicated module for this, with an OpenAPI specification of about 2669 lines and 32 endpoints. The backend generates Java controller interfaces from it, while the frontend uses the same YAML as its single source of truth and maintains TypeScript types by hand to fit real UI scenarios.

The author stresses that speckit.analyze cannot automatically validate consistency across the two repositories at once, so cross-repository checks still have to be done manually through the coordination context. Even so, the setup reduces the risk of silent drift between server and interface: if the API changes, the change is first recorded in the specification and then surfaces when interfaces are generated or the frontend is compiled.

The practical takeaway is fairly blunt: SDD scales, but only if you treat it as a change-management system rather than a way to ask AI to write a feature. On short tasks you may not notice the difference, but over dozens of sprints it is the boring parts of the process that pay off: living constitutions, separate contexts, formal artifacts and regular consistency checks.

The case is interesting because it shows SDD not on a toy MVP but on a project that already has production, a test suite, separate repositories and a real cost for mistakes in architecture and contracts.