\n<\/p>\n
Most founders think the build-versus-buy decision when it comes to backend infrastructure is about engineering tradeoffs. I used to think that too.<\/p>\n
At UNest, I learned the hard way that it\u2019s actually about control. The moment that lesson landed, it permanently changed how I make decisions as a founder.<\/p>\n
This is the story of how that realization happened \u2014 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.<\/p>\n
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.<\/p>\n
As we scaled, we crossed an invisible line. We weren\u2019t just building a product anymore \u2014 we were building on top of infrastructure that increasingly dictated what we could and couldn\u2019t 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.<\/p>\n
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.<\/p>\n
That was our real build-versus-buy moment. Without ownership over certain systems, we didn\u2019t truly control the company\u2019s future.<\/p>\n
I didn\u2019t start with a framework. I developed one by watching which decisions created leverage \u2014 and which quietly introduced risk. Today, every major infrastructure decision runs through the same five questions.<\/p>\n
The first question I ask is simple: What happens if this system fails?<\/p>\n
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\u2019d feel pain \u2014 but not existential risk.<\/p>\n
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.<\/p>\n
Next, I evaluate whether the component directly shapes why customers choose us and stay.<\/p>\n
In our case, parents were trusting us with their children\u2019s financial futures, and the investment account experience sat at the center of that trust. Its reliability and transparency defined our brand. That\u2019s why we built it ourselves. No vendor solution aligned with our long-term vision, and outsourcing it would have meant outsourcing trust.<\/p>\n
By contrast, gifting initially felt like a feature rather than a trust anchor. Customers valued it, but it wasn\u2019t the primary reason they chose us. That distinction mattered when we evaluated whether to build internally or acquire an existing solution.<\/p>\n
The rule I learned is simple: If customers would leave if this breaks, think carefully before outsourcing it.<\/p>\n
Early in my founder journey, I underestimated how dangerous blind optimism can be.<\/p>\n
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.<\/p>\n
Building without expertise can burn time and increase long-term risk.<\/p>\n
There are cases where cultivating expertise is worthwhile. But that should be a deliberate investment \u2014 not something you back into accidentally while trying to ship a feature.<\/p>\n
Founders obsess over build cost and underestimate delay cost.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Buying wasn\u2019t cheaper in theory \u2014 but delay would have been far more expensive in practice.<\/p>\n
This is the question I now never skip.<\/p>\n
When Synapse, the backend provider powering Littlefund, abruptly shut down, we were forced to remove gifting from the product entirely. The failure wasn\u2019t ours \u2014 but it became our problem overnight. We couldn\u2019t simply swap providers without major disruption.<\/p>\n
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.<\/p>\n
In my current company, Mostt, I only buy infrastructure when there is a clear exit path \u2014 technical, contractual or operational. If walking away would cripple the product, I treat that dependency with the same seriousness as an internal system.<\/p>\n
Build-versus-buy decisions aren\u2019t about pride or purity. They\u2019re about deciding where your company can afford fragility \u2014 and where it absolutely cannot.<\/p>\n
The rule I now share with founders is simple:<\/p>\n
Buy what\u2019s interchangeable.<\/p>\n
Build what you cannot afford to lose control of.<\/p>\n
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.<\/p>\n