Vibe coding — I build what I spec
Clickable, deployable prototypes in days, so decisions get made against something real.
A spec asks the reader to simulate the product in their head and then react to the simulation. Most people can't do that reliably, so they react to the writing instead. A prototype removes the simulation step: the reader clicks the thing and knows within ten seconds whether it's right.
What I build
Not a design mockup — a working slice, front to back, on your real data shape. The persistence can be fake. The validation cannot, because that's where the product questions live.
- A real flow, running, that someone outside the team can use unaided.
- Built on the actual data model, so the edge cases surface before engineering finds them.
- Deployed to a URL you can send, not a file you have to open.
Why it changes the meeting
With a spec, people say what they think users would want. With a prototype, they say that's not what I expected to happen. The second is a fact and it's much cheaper to resolve.
- Decisions land in the room instead of deferring to the next review.
- Engineering estimates the thing rather than the document.
- The written spec that follows is short, because the hard part is already settled.
Common questions
- Is this production code?
- No, and it shouldn't be. It's built to answer a question. Some of it survives into production because the data model is real; assume none of it will and you'll be pleasantly surprised.
- Can I buy just a prototype?
- Occasionally, but it's rarely the right purchase on its own. The value is in the decision it unblocks, and that usually needs someone in the room when people react to it.
- What do you build with?
- Whatever gets to a real answer fastest — typically a modern web stack with AI-assisted development. The tooling isn't the point; the working artefact is.
See it on a real problem
Bring the decision that keeps getting deferred. 30 minutes to work out whether something clickable would settle it.
Book a call