The opinions of contributing entrepreneurs are their own. </p><div>
Key Takeaways
- The most important infrastructure decisions founders make often look technical on the surface, but have much deeper strategic consequences.
- Before leaders decide to build or buy, they must challenge their assumptions to avoid hidden risks that could quietly shape the future of their companies.
Most founders think the build versus buy decision when it comes to back-end infrastructure is about technical tradeoffs. I used to think that too.
At UNest I learned the hard way that it’s really about control. The minute that lesson came in, it forever changed the way I make decisions as a founder.
This is the story of how that realization came about – and the five-question framework I now use to decide whether to build or buy, based on real decisions we made as we scaled a regulated fintech company.
Know when building versus buying becomes a control issue
At UNest, we want to modernize the way families save and invest for their children. In the beginning, we were focused on what most founders focus on: building features, refining onboarding, and making a complex financial product feel intuitive.
As we scaled up, we crossed an invisible line. We weren’t just building a product anymore; we were building on top of an infrastructure that increasingly dictated what we could and couldn’t do. Simple features required approval from external partners. The technical timelines were shaped by third party constraints. Compliance requirements forced us to adopt solutions that added vulnerability instead of resilience.
At first I treated this as normal fintech friction. Eventually it became clear that something more fundamental was going on. The key factors affecting speed, risk and reliability were no longer fully under our control.
That was our real build versus buy moment. Without ownership of certain systems, we didn’t really have control over the future of the company.
Use this five-question test before you build or buy
I didn’t start with a framework. I developed one by looking at which decisions created leverage – and which quietly introduced risk. Today, every major infrastructure decision runs through the same five questions.
1. Determine if it is interchangeable or a checkpoint
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 can be replaced with limited disruption. If one supplier were to go bankrupt, we would feel pain, but not existential risk.
Other systems were fundamentally different. Account infrastructure, money movements and compliance workflows impacted customer funds, legal obligations and trust. If those systems were to break, the consequences would ripple throughout the company.
2. Ask if this directly affects customer trust
I then evaluate whether the component directly determines why customers choose and stay with us.
In our case, parents trusted us with their children’s financial future, and the investment account experience was central to that trust. Its reliability and transparency defined our brand. That’s why we built it ourselves. No vendor solution matched our long-term vision, and outsourcing it would mean outsourcing trust.
In contrast, giving initially felt like a marker rather than an anchor of trust. Customers appreciated it, but it was not the main reason they chose us. That distinction was important as we evaluated whether to build in-house or acquire an existing solution.
The rule I learned is simple: if customers would leave if this breaks, think carefully before outsourcing.
3. Be honest about whether you have the expertise to build it properly
Early on in my founding journey, I underestimated how dangerous blind optimism could be.
When we investigated gift giving internally, we assumed we would figure it out. In practice, we lacked deep expertise in the required workflows, and our broker-dealer imposed strict restrictions that limited experimentation. Progress quickly slowed and engineering time was lost in compliance conversations instead of execution.
Building without expertise can save time and increase risk in the long term.
There are cases when cultivating expertise is worth it. But that should be a conscious investment, not something you accidentally come back to while trying to ship a function.
4. Calculate the cost of delay, not just the cost to build
Founders obsess over construction costs and underestimate delay costs.
Every month spent building non-core infrastructure internally was a month not spent improving the core product, deepening engagement, or showing momentum to investors. Those opportunity costs were much more important than the technical budget item.
This realization ultimately led us to acquire Littlefund instead of continuing to develop gifting ourselves. Structuring the deal as an all-stock acquisition saved money and solved the problem immediately.
Buying was not cheaper in theory, but delaying it would have been much more expensive in practice.
5. Make sure you can walk away when you buy something
This is the question I will never skip anymore.
When Synapse, the backend provider that powers Littlefund, was abruptly shut down, we were forced to completely remove gifting from the product. The failure was not ours, but it became our problem overnight. We couldn’t just switch providers without major disruptions.
That moment forever changed the way I think about third-party risk. If a failing supplier takes your product, you never really owned the outcome.
In my current company, Mostt, I only buy infrastructure if 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
Building versus buying decisions are not about pride or purity. It’s about deciding where your business can afford to be vulnerable – and where it absolutely cannot.
The rule I now share with founders is simple:
Buy what is interchangeable.
Build what you can’t afford to lose control of.
If I had applied that rule earlier, it would have saved us time, focus and risk. I hope it helps other founders make the decision before the consequences become as real as they were for me.