Home / Blog / I built a retrospective board in under an hour
I built a retrospective board in under an hour
For a long time I had been thinking about building a self-hosted retrospective board. It was one of those ideas that sat on the list, potentially a weekend side project, potentially something to hand off to an intern. Useful enough to want, not urgent enough to prioritise. You know the kind.
With the recent wave of AI tooling, I decided to stop thinking about it and actually test something: what does spec-driven development really look like in practice today?
The answer turned out to be pretty surprising.
What I actually built
A retrospective board with the basics you'd expect: columns for what went well, what didn't, what to try next, the ability to add and organise cards, vote on items. Nothing fancy, but genuinely functional. Self-hosted, runs locally.
The full code is here: achintmehta/retrospective-board
The build time, start to finish: under an hour.
To be clear about what this was and wasn't: this is not production-ready software. It wasn't meant to be. There's no auth, no persistence layer worth shipping, no error handling for edge cases. The goal was to probe the ceiling of rapid prototyping with modern models and see how far spec-driven development can take you before the wheels fall off.
What it looks like
The dashboard where you manage your boards:
And the board view where the actual retrospective happens:
What spec-driven development actually means
The term gets used loosely, so here's what I mean by it. Instead of opening an editor and writing code, you start by writing a spec: a clear description of what you want, how it should behave, what the constraints are, what trade-offs you're willing to make. You treat the AI as the implementer and yourself as the product owner and architect.
In practice this means:
- Writing a clear problem statement before touching any code
- Decomposing the problem into discrete chunks the model can reason about independently
- Being explicit about constraints: tech stack, data model, interface behaviour
- Reviewing output critically, not just accepting whatever comes back
- Iterating on the spec when the output is wrong, not just the prompt
It sounds obvious when written out. In practice it requires a different discipline than just asking "write me a retro board app" and hoping for the best.
What worked well
The speed is real. For a bounded, well-understood problem like a retro board, a modern model can produce working code faster than I can scaffold a project manually. The basic CRUD, the UI layout, the state management: all of it came out reasonably clean on the first or second pass.
The key was front-loading the thinking. When I gave the model a vague brief, the output was vague. When I gave it a precise spec with specific columns, specific interactions, and a specific data shape, it delivered something much closer to what I actually wanted.
For well-understood problem domains, this workflow is genuinely fast. The AI is not just autocomplete at this point, it's doing real implementation work.
Where the cracks show
The further you get from the happy path, the more the model needs guidance. Edge cases, error handling, integration with external systems, anything that requires deep knowledge of your specific context: these still need a human in the loop thinking carefully.
It also doesn't replace the cost of thinking clearly about what you want. If anything, it makes that cost more visible. Vague thinking used to produce slow, vague code. Now it produces fast, vague code. The feedback loop is tighter but the underlying problem is the same.
What this means for developers
My takeaway is pretty clear. As code generation becomes faster and cheaper, the value shifts. The raw ability to type implementation quickly matters less. What matters more:
Requirements gathering: understanding what actually needs to be built, not just what was asked for. This is harder than it sounds and AI doesn't do it for you.
Problem decomposition: breaking a complex system into pieces that can be reasoned about independently. The better you are at this, the better the AI output.
Systems thinking: understanding how components interact, where the failure modes are, what the data model needs to look like upstream of any implementation.
Asking the right questions: knowing what you don't know. Knowing when the spec is incomplete before you start.
Making the right trade-offs: every design has trade-offs. AI can implement what you decide, but deciding well is still a human job.
In the AI era, lateral thinking and clarity of thought may matter more than raw implementation speed. The developer who can think clearly about a problem, decompose it well, and review output critically will get dramatically more out of these tools than someone who just types faster.
That's what an hour with a retro board taught me.