Quick answer: Build when the capability is a strategic differentiator or scale economics will eventually tip; buy when the capability is plumbing your competitors get from the same vendors at the same prices and you have other places to invest engineering. The mistake most companies make is building plumbing and buying differentiators — the exact inverse of what compounds value. Run the math properly: engineers are not free, and annual maintenance runs 20-30% of the original build cost.
Every software-using business eventually faces the build-vs-buy question, often many times. The wrong framework treats it as engineering capacity ("we have engineers, so we can build it") or as a single binary ("we either build or we buy"). The right framework treats it as a strategic question with a specific answer for each capability — and accepts that the answer changes as the business evolves.
In plain language: build when the capability is a strategic differentiator or scale economics will eventually tip; buy when the capability is plumbing your competitors get from the same vendors at the same prices and you have other places to invest engineering. The mistake most companies make is building plumbing and buying differentiators — the exact inverse of what compounds value.
The Wardley-style mental model
For any capability in your stack, ask:
- Is it genesis (novel, undefined, custom)?
- Is it custom-built (specialised to you)?
- Is it product (well-defined, off-the-shelf available)?
- Is it commodity / utility (mature, undifferentiated, available cheap)?
Build the genesis. Build the custom where it's a differentiator. Buy the product. Buy the commodity.
The error pattern: building product because "we want control" or buying genesis because "there's a vendor that claims to do this." Both bleed value.
The four-question decision framework
For any specific capability, work through:
1. Is this a strategic differentiator?
If customers buy from you partly because of how this capability works, building gives you the differentiator no vendor will. If customers don't notice this capability — it's table stakes plumbing — vendors do it as well or better than you would.
2. What's the genuine TCO over five years?
Build TCO: engineering build + maintenance (typically 20-30% of build cost annually) + opportunity cost of those engineers not building elsewhere + tooling + observability + security + on-call.
Buy TCO: subscription / per-unit cost + integration engineering + vendor management + switching cost when you eventually want to leave.
Run the math properly. "We have engineers, so the build is free" is the most common modelling error. Engineers are not free — they have an opportunity cost, and that cost is the next best thing they could be building.
3. What's the time-to-value?
Build: months to first production capability, more to first stable version. Buy: days to weeks usually.
If your strategic timeline demands quick deployment, buy decides itself. If you have engineering runway and the capability isn't urgent, build may compete.
4. What's the switching cost in either direction?
If you build now and want to buy later, you have to migrate from a custom system — typically painful. If you buy now and want to build later, you have to leave a vendor and bring data and workflow in-house — also painful but typically less so.
The asymmetry matters: from a buy-now position you can usually still build later. From a build-now position, switching to buy means abandoning sunk engineering. Default-to-buy is the safer bet when you're uncertain.
What you should almost always buy
- Identity & authentication (Auth0, Okta, etc. unless you're an identity company)
- Payment processing (Stripe, Razorpay, etc.)
- Email infrastructure (SendGrid, Postmark, etc.)
- Analytics tooling (the product analytics + BI stack)
- Customer support (Zendesk, Intercom)
- CRM (you're not Salesforce; don't build a CRM)
- HR / payroll / billing (Zoho, Stripe Billing, etc.)
- Infrastructure primitives (cloud, observability, CDN)
Building any of these without an unusually strong reason is wasted engineering.
What you should almost always build
- Core product features that differentiate you
- Proprietary algorithms that are your competitive moat
- The unique workflows that define your business operating model
- Data structures that no vendor models well enough
- Customer-facing UX that you want absolute control over
The grey zone where most mistakes happen
- Internal tools — buy when generic, build when bespoke
- Industry-specific verticalised tooling — buy when a vertical SaaS does it well, build when the vertical is too niche
- Integrations — usually buy via iPaaS, build when the integration is a core part of your product
- Operational dashboards — buy unless you genuinely need bespoke views
The pattern that compounds: ruthlessly buy in the grey zone for the first three years; revisit each grey-zone purchase annually; build only when buying genuinely fails.
The hybrid pattern
You don't have to choose pure build or pure buy. The pattern that scales:
- Buy the platform with the most adjacencies and the lowest switching cost
- Build the differentiation on top of it
- Maintain switch-ability by abstracting vendor dependencies behind your own interfaces
This is the pattern most mature engineering organisations end up with. The early days are about choosing wisely; the mature days are about preserving optionality.
When build economics genuinely tip
There are cases. The genuine ones:
- Scale economics — at very high volume, vendor per-unit costs exceed the cost of running your own
- Strategic moat — the capability is a moat, vendor is generic, building is a defensible advantage
- Regulatory requirements that no vendor handles in your jurisdiction
- Data sovereignty requirements
- Compounding learning — owning the capability lets you iterate faster than vendors
The fake ones:
- "We can build it cheaper" (with under-modelled TCO)
- "We don't trust vendors" (usually means "we haven't done vendor management well")
- "We need control" (usually means we don't want to model the cost of true control)
How OpenMalo thinks about this
We deliver to a wide range of clients across FinTech, Healthcare, Real Estate, and Marketing. The pattern that compounds:
- Buy the modules where your competitors all do roughly the same thing (KYC, payments, identity, observability)
- Build the modules where your operating model is your competitive advantage
- License OpenMalo's modular products where they accelerate your time-to-market for compliant infrastructure — KYC, lending, telemedicine, ABDM integration, RERA-compliant property listings, WhatsApp / SMS / email orchestration
The honest pitch: we're not the right buy for everything you do. We're the right buy when the capability fits our modules and you'd rather invest engineering on what actually differentiates you.
CTA: Browse the OpenMalo product modules — each is the "buy" answer for a specific compliance-heavy capability that doesn't differentiate your business. See the module →
Closing
Build vs buy isn't an ideology. It's a decision you re-make per capability, with honest TCO modelling and a clear-eyed view of what actually differentiates your business. The teams that decide well end up with engineering investment compounding on the work that matters and vendor relationships compounding on the work that doesn't.
