When a demo works, publishing the architecture notes can do more for distribution than sending another cold email. The notes turn a private proof into an artifact that lets the right builders judge the reasoning, the trade-offs and the risks before they decide to reply.
On Friday, the demo finally held together long enough to stop feeling like a performance. The path worked. The output made sense. The failure cases we had been watching did not appear in the run we showed.
That is usually the moment a founder opens a prospect list.
We did something else. We wrote down the decisions that made the demo possible: what we had simplified, what we had deferred, where human review still sat in the path, and the assumptions that would break under real customer behaviour. Then we published the notes.
A working demo can hide the work that matters
A demo earns attention because it makes the outcome visible. It rarely explains whether the outcome can survive contact with a customer, a new data source or a person who uses the product in a way nobody predicted.
That missing explanation was the useful part.
The notes gave the demo a boundary. We could say which decisions were temporary, which were deliberate, and which risks still needed evidence. A product builder reading it could see more than a polished result. They could see the call behind it.
For a founder with limited runway, that distinction matters. A cold email asks someone to make time for a claim. A useful technical note gives them something concrete to inspect first. It can reach an engineer deciding whether the architecture makes sense, a founder wondering if the same shortcut applies to their product, or a potential client trying to understand how you reason when the brief becomes unclear.
The point was not to make the work look finished. It was to make the work legible.
Linus Torvalds made the unfinished work visible
In August 1991, Linus Torvalds posted to the comp.os.minix newsgroup about the operating system he was building for 386 AT clones. He described it as a hobby project and asked what features people wanted in MINIX.
The outcome was still open. He had a working direction, not a finished platform, a community or proof that other people would care enough to contribute. His post gave technically minded readers a way into the work while it was still taking shape.
The archived comp.os.minix post shows why this remains a useful distribution lesson. Torvalds did not wait for a complete story. He made the current state inspectable and invited response around the decisions that mattered.
A founder publishing architecture notes is working on the same mechanism at a smaller scale. You give people a reason to engage with the actual problem, rather than asking them to react to a finished-looking claim.
That does not mean publishing every internal detail. Customers may have data that must remain private. Some implementation choices create security risk when exposed. Some experiments are too early to deserve a public narrative.
It means choosing the parts that make your judgment visible: the constraint, the alternative you rejected, the compromise you accepted and the evidence you still need.
The unresolved risks made the piece stronger
We could have written a victory post. It would have been easier to share and less useful to anyone building a serious product.
Instead, the unresolved risks gave the notes their weight. A reader could see where the demo depended on an assumption and where a person still needed to intervene. That is closer to the decision an early-stage team faces every week: ship the useful version now, then decide what evidence must arrive before more automation is safe.
This is especially important with AI products. A model can produce a convincing answer in a controlled run and still fail when a customer brings incomplete information, unexpected language or a disputed action. The right question is often less about whether the demo works and more about what happens when it does not.
That was the core of the decision to ship an AI agent in Berlin with human approval. Human approval was part of the product boundary, not an embarrassing gap to conceal.
Publishing the boundary helps the right people self-select. Some will disagree with the choice. That can be useful too, provided they are disagreeing with the actual decision rather than a vague impression of your competence.
Publish the decision record while it is still useful
A useful architecture note does not need a grand conclusion. Start with the moment a real choice appeared.
Explain the customer outcome you were protecting. Name the constraint that ruled out the cleaner option. Show the compromise. End with the risk you have not resolved.
Then publish it while the decision is current enough for someone else to recognise their own version of it.
Torvalds’s 1991 post mattered because it exposed work that was still becoming. Our Friday notes carried the same modest bet: the demo was worth more when the reasoning around it could travel too.
Comments
No comments yet.