There’s a difference between a demo and a prototype. A demo is what you show; a prototype is what you learn from. We build prototypes — working slices of the real thing, with real data flowing through real auth, hitting real failure modes. Fast enough to learn quickly, real enough to make the next decision honestly.
What this looks like in practice
Two-to-six week build cycles. Weekly demos to whoever’s funding the work. The slice does the most decision-relevant thing end-to-end — not the most impressive thing visually. By week three we know which parts of the original assumption survive contact with reality and which don’t. By week six there’s either a tear-down decision or a scale-up plan, with information to back either.
For a worked example of “design once, ship the deterministic part as code” — which is half of what good prototypes do — see The 14-Cent Workflow. The expensive model thinks once, emits Python, and skips itself on every future run.
Who this fits (and who it doesn’t)
Fits: teams between “we have an idea” and “we have a product.” Founders who need real signal before raising. Internal product owners trying to convince leadership that a thing is worth funding. Researchers who need an artifact, not a paper.
Doesn’t fit: if you already have product-market fit and need scale engineering, this isn’t the right shape. If you need a clickable Figma deliverable, that’s a designer.
The first conversation
We’ll ask what decision the prototype is supposed to inform. The clearer the decision, the tighter the build.