Key Takeaways
- The most important infrastructure decisions founders make often look technical on the surface but carry far deeper strategic consequences.
- Before choosing to build or buy, leaders should pressure-test their assumptions to avoid hidden risks that can quietly shape their company’s future.
Most founders think the build-versus-buy decision when it comes to backend infrastructure is about engineering tradeoffs. I used to think that too.
At UNest, I learned the hard way that it’s actually about control. The moment that lesson landed, it permanently changed how I make decisions as a founder.
This is the story of how that realization happened — and the five-question framework I now use to decide whether to build or buy, grounded in real decisions we made while scaling a regulated fintech company.
Know when build vs. buy becomes a control issue
At UNest, we set out to modernize how families save and invest for their kids. In the early days, we were focused on what most founders focus on: building features, refining onboarding and making a complex financial product feel intuitive.
As we scaled, we crossed an invisible line. We weren’t just building a product anymore — we were building on top of infrastructure that increasingly dictated what we could and couldn’t do. Simple features required approval from external partners. Engineering timelines were shaped by third-party constraints. Compliance requirements forced us into workarounds that added fragility instead of resilience.
At first, I treated this as normal fintech friction. Eventually, it became clear that something more fundamental was happening. Key factors influencing speed, risk and reliability were no longer fully under our control.
That was our real build-versus-buy moment. Without ownership over certain systems, we didn’t truly control the company’s future.
Use this five-question test before you build or buy
I didn’t start with a framework. I developed one by watching which decisions created leverage — and which quietly introduced risk. Today, every major infrastructure decision runs through the same five questions.
1. Determine whether it’s interchangeable or a point of control
The first question I ask is simple: What happens if this system fails?
Some tools were clearly interchangeable. Internal productivity software, analytics platforms and support tools could be replaced with limited disruption. If one vendor went down, we’d feel pain — but not existential risk.
Other systems were fundamentally different. Account infrastructure, money movement and compliance workflows touched customer funds, regulatory obligations and trust. If those systems broke, the consequences would cascade through the entire business.
2. Ask whether it directly shapes customer trust
Next, I evaluate whether the component directly shapes why customers choose us and stay.
In our case, parents were trusting us with their children’s financial futures, and the investment account experience sat at the center of that trust. Its reliability and transparency defined our brand. That’s why we built it ourselves. No vendor solution aligned with our long-term vision, and outsourcing it would have meant outsourcing trust.
By contrast, gifting initially felt like a feature rather than a trust anchor. Customers valued it, but it wasn’t the primary reason they chose us. That distinction mattered when we evaluated whether to build internally or acquire an existing solution.
The rule I learned is simple: If customers would leave if this breaks, think carefully before outsourcing it.
3. Be honest about whether you have the expertise to build it well
Early in my founder journey, I underestimated how dangerous blind optimism can be.
When we explored building gifting internally, we assumed we could figure it out. In practice, we lacked deep expertise in the required workflows, and our broker-dealer imposed strict constraints that limited experimentation. Progress slowed quickly, and engineering time disappeared into compliance conversations instead of execution.
Building without expertise can burn time and increase long-term risk.
There are cases where cultivating expertise is worthwhile. But that should be a deliberate investment — not something you back into accidentally while trying to ship a feature.
4. Calculate the cost of delay, not just the cost to build
Founders obsess over build cost and underestimate delay cost.
Every month spent building non-core infrastructure internally was a month not spent improving the core product, deepening engagement or demonstrating momentum to investors. That opportunity cost mattered far more than the engineering budget line item.
This realization ultimately led us to acquire Littlefund instead of continuing to build gifting ourselves. Structuring the deal as an all-equity acquisition preserved cash and solved the problem immediately.
Buying wasn’t cheaper in theory — but delay would have been far more expensive in practice.
5. Make sure you can walk away if you buy
This is the question I now never skip.
When Synapse, the backend provider powering Littlefund, abruptly shut down, we were forced to remove gifting from the product entirely. The failure wasn’t ours — but it became our problem overnight. We couldn’t simply swap providers without major disruption.
That moment permanently reshaped how I think about third-party risk. If a vendor failure takes your product with it, you never truly owned the outcome.
In my current company, Mostt, I only buy infrastructure when there is a clear exit path — technical, contractual or operational. If walking away would cripple the product, I treat that dependency with the same seriousness as an internal system.
Follow this rule to avoid costly infrastructure mistakes
Build-versus-buy decisions aren’t about pride or purity. They’re about deciding where your company can afford fragility — and where it absolutely cannot.
The rule I now share with founders is simple:
Buy what’s interchangeable.
Build what you cannot afford to lose control of.
If I had applied that rule earlier, it would have saved us time, focus and risk. My hope is that it helps other founders make the call before the consequences become as real as they were for me.
About The Author
