Why I still prototype things myself
A prototype is the cheapest way to find out whether you understand a problem. Why I still build them myself, and what I try to learn from each one.
I co-founded a company, I have a title with officer in it, and I still write code.
That can look odd. The usual assumption is that at some point you stop building and start directing: you write the strategy, someone else writes the code.
I understand the logic. I just don’t think it holds up very well, and less so every year.
A prototype is a question with a deadline
Most ideas look good in a document.
A document lets you skip the parts you haven’t thought about. It lets two people agree on a sentence while imagining completely different systems. It never fails to compile.
A prototype doesn’t give you that comfort. The moment you build something, even a crude version, the vague parts become obvious. Where does this data actually come from? What happens on the second run? Who is allowed to do this? What does the user see while they wait?
So I think of a prototype less as a first version of a product and more as a question with a deadline. The question is usually some form of: do I actually understand this?
Often the answer is no. That is the useful part.
Cheap answers to expensive questions
A recent example: I wanted to know whether a new, fast decision model had any short-horizon trading value.
Questions like that can turn into weeks of discussion. This one became a small, isolated harness: live market data, paper trading with real fees and slippage, cached model answers, and a set of boring baselines to compare against.
The first useful output wasn’t even from the model. It was a cost floor: how much the market has to move in a given window before a trade can pay for itself. At the horizon I started with, it was effectively impossible. Every later result agreed.
The model did produce one exciting run along the way: 8 correct calls out of 9. That disappeared at 31 trades and again at 85. Small samples lie in your favour.
The final answer was a clear no, for about 20 cents of model usage.
I don’t think I would have trusted that answer as much if someone had summarised it for me. Building it myself meant I knew exactly which assumptions were in the harness, which ones weren’t, and where the result could be wrong.
Understanding doesn’t delegate well
A lot of work can be delegated. Understanding is harder.
If I want to make good decisions about systems, I need an accurate model of how they behave. Not the architecture diagram. The actual behaviour: where it is slow, what breaks, which abstraction is leaking, what looked simple and wasn’t.
Much of that knowledge only comes from contact. Reading about a new model is not the same as watching it make 500 decisions and noticing where it hesitates. Reviewing a design for agent memory is not the same as discovering that your agent is confidently remembering something that stopped being true weeks ago.
At Agio Digital I spend most of my time building, prototyping, reviewing systems and figuring out what we should do next. Those activities feed each other. Prototyping makes my reviews better. Reviews tell me what is worth prototyping.
It keeps the conversation honest
There is also a quieter benefit.
Once a rough version of something exists, conversations about it change. We stop debating whether an idea could work and start looking at what the prototype showed. Disagreements become specific. This part was slow. This step confused people. This assumption was wrong.
A working prototype is hard to argue with in the abstract. That is a feature.
It also cuts the other way. If I propose something and can’t make even a crude version work, that tells me something about the idea, or about my understanding of it, before anyone else has spent time on it.
AI changed the economics
A few years ago, the argument against founders prototyping was partly about time. Building even a rough version of something could take days, and those days had other uses.
That cost has dropped a lot. With agents and good tooling, a prototype that used to take a week can often exist in an afternoon. Scaffolding, glue code and the fifth form field are no longer where the time goes.
So the remaining time goes into the part that matters: deciding what to build, what to measure and what the result means.
If anything, that makes prototyping more appropriate for someone whose job is to figure out what to do next, not less.
What I try to get right
A few habits make prototypes more useful to me:
- Decide the question first. A prototype without a question is just an unfinished product.
- Keep it isolated. Nothing it touches should be hard to delete. The trading harness imported nothing from the rest of the codebase it lived in, on purpose.
- Compare against something boring. A result only means something next to a baseline. Often the baseline wins.
- Label fakes clearly. One of my experiments falls back to a simple heuristic when no API key is present, and the interface labels it DEMO POLICY. No fake model results, even in a demo.
- Leave out infrastructure you don’t need yet. The first release of that same experiment has no database: replays are self-contained links.
- Write down what you learned. A prototype you learned nothing from was just a hobby. Which is also fine, but it helps to know which one it was.
The open question
The part I’m less sure about is scale.
Prototyping myself works when I’m close to the problem. As companies grow, the gap between what one person can build and what the organisation needs gets wider. At some point the prototype becomes a bottleneck, or a toy that doesn’t reflect the real constraints.
I don’t think the answer is to stop. I think it is to be selective: prototype where understanding is the scarce resource, and delegate where it isn’t.
I still enjoy opening an empty repository and figuring something out. Some of those repositories become useful. Some answer a question.
That’s enough.