Every product starts with an idea and uncertainty.
Demand may be unclear. The market may be early. Regulation may block the model. The technology may not support it. These uncertainties determine whether the idea deserves to become a product.
The job is not to eliminate uncertainty before acting. It is to reduce the uncertainty that matters most before making expensive decisions around it.
The mistake isn't being uncertain. It's spending like you're certain.
Teams get into trouble when assumptions become expensive too quickly: a large implementation before demand is understood, or a platform before a durable pattern exists. The opposite failure is waiting for certainty that can only be created through action.
Uncertainty is a reason to prototype, not a reason to stop building. What you avoid is premature durability: decisions that become expensive to change before the evidence supports them.
Find the highest-leverage uncertainty
An idea usually contains many uncertainties, and they are not all technical. Demand, market timing, regulation, and technical feasibility can all invalidate the idea. You cannot investigate everything with equal depth at once.
The first question should be: What is the highest-leverage uncertainty?
Find the unknown whose resolution would eliminate the most bad paths or unlock the most useful next steps. Then find the fastest credible way to reduce it.
An experiment does not necessarily mean writing code. It might be a prototype, customer research, regulatory analysis, or something put in front of users. What matters is whether it produces evidence strong enough to change what you believe.
The loop itself is not new: hypothesize, experiment, gather evidence, update. At the beginning, the space of possible answers is wide. Useful experiments remove paths, reveal constraints, and show you what matters next.
Clarity is knowing enough to make the next decision with less guesswork. It is not certainty. As clarity grows, the way you build should change with it.
The Phantom Cash prototype was not the product
When we started working on what became Phantom Cash, the direction was compelling but the implementation space was enormous.
We needed capabilities across identity, KYC, banking integrations, stablecoins, activity tracking, payment flows, cards, and infrastructure that Phantom did not yet have in the form we needed.
We could have started by designing the whole system. It would have looked responsible and could have taken years before answering the most basic questions.
The highest-leverage uncertainty was much more basic: how difficult was the provider integration, and could the underlying primitives support the product at all?
I built a small integration outside the main product and started exploring Bridge's APIs. The goal was deliberately narrower than building Phantom Cash: we were buying information, not building the final system.
The prototype showed that the underlying model was possible. We learned how virtual accounts worked, how cards connected to the system, and where the model did not fit neatly into the existing Phantom wallet architecture.
The evidence did not answer everything, but it answered enough to change the question from “Can this work?” toward “How should this fit into our product?” That justified a different kind of work: product design, a real first iteration, and more people focused on turning the idea into something users could use.
The progression is not a jump from prototype to “production.”
Clarity should change how you engineer
Early in a product, you rarely know enough to predict every place the system will change. Abstracting all of those possibilities is not designing for change; it is guessing.
Don't abstract too early. Wait for the pattern.
An abstraction becomes justified when the pattern is observed rather than imagined. Repetition is one way that happens, but not a rule about how many times something must occur. A second provider may reveal what belongs behind a common interface; a workflow adopted by multiple products may reveal a durable capability. The same logic applies to platforms.
Don't build platforms for theories. Build them for observed, durable patterns.
A platform is not merely reusable code. It creates contracts, dependencies, operational expectations, and often organizational boundaries—things that are expensive to unwind. Durability should follow evidence, not precede it.
The signals are usually visible. They are signals, not a checklist.
Repetition. You are solving the same problem again.
Usage. Real users or internal systems now depend on it.
Friction. The temporary solution is making the next change slower.
Coordination. Knowledge or decisions are becoming bottlenecks.
When these signals appear, making the system more durable is not premature optimization. It can be the fastest way to keep moving.
Heroics have an expiration date
I saw this transition clearly at BitGo.
As traffic grew, we supported more chains and the system became more complex. Continuing to add capabilities through the same concentrated, heroic model became increasingly expensive. The shortcuts that had helped us move quickly were becoming technical debt.
Technical debt is not automatically a failure. Early on, imperfect code can buy learning and speed. The question is whether that debt is still buying speed or has started slowing every new change.
The only reliable way to avoid technical debt entirely is not to write code.
At BitGo, there came a point where the existing architecture was no longer well positioned for the rate and shape of change we needed. Adding capabilities was getting harder, and the same classes of problems kept returning.
At that point, durability was buying speed. That meant dedicated infrastructure work, specialized talent, clearer ownership, and teams capable of building a platform for continued iteration.
The heroics had worked, but heroics have an expiration date.
Heroics create momentum. Permanent heroics create a ceiling.
Ownership has the same timing problem as architecture.
Create team boundaries too early and you add handoffs around something that is still changing rapidly. Wait too long and knowledge concentrates in a few people, decisions queue behind them, and rescue work becomes normal.
Ownership should follow durable responsibility. A temporary problem does not necessarily need a team; a capability that repeatedly matters and needs independent evolution probably does.
A company does not move neatly from “prototype mode” to “scale mode.” Clarity belongs to a problem, not to a company. An exploratory team should optimize for learning and reversibility; a mature platform should optimize for reliability, adaptability, and clear ownership.
Cheap code makes this more important, not less
These ideas are becoming more important because the economics of software are changing.
AI-assisted development is making many forms of implementation dramatically cheaper. Prototypes can be produced faster, alternatives explored cheaply, and code discarded with less regret.
That is a huge advantage for ambiguous product work, but it also makes it easier to turn weak assumptions into large systems simply because writing the code no longer feels expensive.
AI makes code cheaper. It does not make evidence or bad decisions free.
As code gets cheaper, judgment gets more valuable.
The scarce skill becomes knowing what deserves to be built, what deserves to be thrown away, and what has survived enough contact with reality to become durable.
Build with the clarity you have
Every idea begins with uncertainty. Find the highest-leverage uncertainty and reduce it as fast as you credibly can. Let the evidence determine what deserves to become durable.
A useful sanity check: if the problem is still poorly understood, why are eight engineers building a platform for it?
The less you know, the less you should build to last. As clarity grows, so should the durability of what you build.