Why This Decision Is So Often Wrong
Build vs buy gets made incorrectly in both directions constantly. Teams build things they should buy (reinventing commodity infrastructure), and buy things they should build (outsourcing core competitive differentiation). Both mistakes are costly.
The errors come from applying the wrong heuristics: "SaaS is expensive", "vendors lock you in", "our requirements are unique", "we need to own the IP". These are real considerations, but they're not the right starting point.
The Right Starting Question
The right question is: is this a source of competitive differentiation?
If yes — if the capability is part of what makes your product better than alternatives — build it, own it, invest in it. This is where your engineering resource should be concentrated.
If no — if it's infrastructure that every business in your category needs — buy it. Your competitors are already using Stripe, Braintree, SendGrid, Twilio. You will not win by building a better payment processor than Stripe.
The Hidden Costs of Building
Teams dramatically undercount the cost of building:
Maintenance burden: Every line of code you write, you own forever. It needs to be maintained, updated for security vulnerabilities, extended for new requirements, and understood by engineers who join years after the original author left.
Opportunity cost: The engineers who built your custom subscription billing system could have been building the features that differentiate your product. That's the real cost.
The last 20% problem: Internal tools built to solve 80% of the problem rarely get the last 20% built. Edge cases accumulate, users work around limitations, and the tool slowly becomes technically inferior to the commercial alternative while still requiring maintenance.
When to Buy Without Hesitation
- ·Payment processing (Stripe/Braintree)
- ·Email delivery (SendGrid/SES)
- ·Authentication (Auth0/Cognito — unless auth is your product)
- ·Infrastructure monitoring (DataDog/NewRelic)
- ·Error tracking (Sentry)
- ·Feature flags (LaunchDarkly)
- ·Subscription billing (Chargebee/Recurly)
When to Build
- ·Your core product experience
- ·Capabilities that encode proprietary business logic
- ·Integration glue between systems (but be suspicious here — often buildable with low-code tools)
- ·Things where the commercial options genuinely don't fit your requirements (rare)
The Freddie's Flowers Replatforming
When I joined Freddie's Flowers as CTO, we faced a classic replatforming decision. The existing platform had grown organically and had significant technical debt in the subscription and fulfilment areas. The question: rebuild it, or adopt a SaaS platform?
We evaluated both paths carefully:
- ·Commercial options (Shopify Plus + Recharge, etc.) didn't fit the complexity of our subscription model
- ·The subscription logic was genuinely our differentiation — weekly personalised flower bundles, dynamic fulfilment windows, complex pause/skip/swap logic
Build won. But we were disciplined about what we built and what we integrated: we built the subscription engine and fulfilment workflow, and bought everything else (Braintree for payments, Looker for analytics, third-party logistics APIs).
The outcome validated the framework: owning the subscription engine let us iterate on it rapidly. The commercial integrations we used saved months of engineering time on non-differentiating work.
Know the difference. Apply the framework. Then stick to your decision — second-guessing a build decision 6 months in because it's harder than expected is usually a mistake.