Build vs buy software: a framework for making the call
The build vs buy software decision rests on one question: does this capability make customers choose you over a competitor? If it does, build it and own it. If it doesn’t, buy it, and spend your engineers on what does. Then check the answer against total cost of ownership and the cost of leaving the vendor later.
That sounds simple, and teams still get it wrong in both directions. They build their own auth, billing or search because it looks easy, and they buy a platform for their core workflow and spend years fighting its limits. Here’s the framework I use.
Core vs context
Split every capability into two groups. Core is what makes your product different and what customers pay for. Context is everything you need to operate but that nobody chooses you for.
For most SaaS companies, context includes authentication, email delivery, payments processing, error tracking, logging, feature flags, analytics, customer support tooling and infrastructure. Core is usually a narrow slice: your domain logic, your workflow, your data model, and the experience built on top.
Build core. Buy context. Most bad decisions come from misclassifying one or the other. A team that thinks its login page is a differentiator will spend a quarter on password reset flows. A team that buys a generic workflow engine for its main product will find the product can only do what the engine allows.
Total cost of ownership: building
The cost of building is rarely the first version. It’s everything afterwards:
- Initial build: design, engineering and testing time, usually underestimated. Use ranges; see software estimation.
- Maintenance: bug fixes, dependency upgrades, security patches, framework migrations. Every line of code you write is a line you maintain.
- Operations: hosting, monitoring, on-call, incidents, backups.
- Compliance and security: audits, penetration tests, data-protection obligations. Building your own auth or payment storage brings these with it.
- Opportunity cost: what your engineers didn’t build instead. Usually the largest number, and the one most often left out.
- Key-person risk: the one engineer who understands the in-house system leaves.
Total cost of ownership: buying
Buying isn’t free either. The subscription is the visible part:
- Subscription or usage fees, and how they grow with your users, seats or volume. Model the price at 5x and 10x your current usage; per-seat and per-event pricing can become your largest software cost. Check the vendor’s current pricing page rather than relying on old numbers.
- Integration work: connecting it, mapping your data to its model, handling webhooks and failures.
- Workarounds: the features you need that it doesn’t have, built around it rather than in it.
- Vendor risk: price increases, product changes, acquisition, outages, or the vendor shutting down.
- Exit cost: what it would take to leave, covered next.
Exit costs: the part teams forget
Before buying, ask: if this vendor doubled its price or shut down in a year, what would it take to replace it? The answer depends on a few things you can check up front:
- Data export. Can you get all your data out, in a usable format, through an API or bulk export? Test it during evaluation, not when you need it.
- Proprietary logic. Workflows, rules or scripts configured inside the vendor’s tool don’t move. The more business logic lives there, the higher the exit cost.
- Integration surface. Wrap the vendor behind your own interface in code (a thin module or adapter). Then replacing it means changing one module, not hundreds of call sites.
- Identifiers. If customer-facing IDs, payment tokens or URLs come from the vendor, migrating is far harder. Payment card tokens are a classic example: moving them between processors is possible but takes coordination with both.
High exit cost doesn’t mean don’t buy. It means buy deliberately, and from a vendor likely to be around in five years.
The questions that settle it
- Is this core or context? If customers would choose you because of it, lean build.
- Is there a mature product that does 80% of what we need? If yes and it’s context, buy.
- What is the three-year total cost of each option, including maintenance, operations and engineer time?
- How hard is it to leave? Check data export, proprietary logic and identifiers.
- Do we have the skills to build and run it well? Payments, auth and search are deceptively deep.
- What would our engineers build instead? If the answer is a core feature customers are asking for, that’s the real cost of building.
- Can we start by buying and build later? Often the best answer: buy now, wrap it behind an interface, and revisit when you hit real limits.
Common build vs buy calls for SaaS
- Authentication: usually buy, or use a well-maintained library in your framework. Building your own password storage, MFA and SSO is high risk and rarely a differentiator.
- Payments: buy the processor; never handle raw card data yourself. But the billing logic around it (plans, usage, invoicing rules) is often worth owning if your pricing is unusual. My book, the Payments Playbook, covers building payment systems in depth.
- Search: start with your database’s full-text search; buy or adopt a dedicated engine when relevance becomes a product feature.
- Internal admin tools: buy a low-code tool for simple CRUD; build when the admin workflow is complex and used all day.
- Analytics and observability: buy. Running your own at small scale is rarely worth it.
- AI features: buy the model via an API; build the retrieval, prompts, evaluation and workflow around it, because that’s where your product lives.
When to revisit a decision
Build vs buy isn’t permanent. Revisit when a vendor’s cost becomes a significant line item, when workarounds take more engineering time than a build would, when the capability moves from context to core, or when the vendor changes direction.
Equally, revisit builds. In-house systems that were once necessary often have good commercial replacements a few years later, and retiring them frees up a team. That’s a common part of legacy modernization.
If you’re facing a big build vs buy decision and nobody on the team has made one at this scale before, it’s the sort of call a fractional CTO is there for, and a good thing to settle before it goes on the technology roadmap.
Questions
When should you build software instead of buying it?
Build when the capability is core to why customers choose you, when no product covers the essential requirements, or when vendor costs at your expected scale clearly exceed the full cost of building and maintaining it yourself. Otherwise, buy and spend engineering time on your differentiators.
What is total cost of ownership in build vs buy?
The full cost over several years, not just the first version or the first invoice. For building, that includes maintenance, upgrades, operations, security and the features your engineers didn’t build. For buying, it includes fees at future scale, integration, workarounds, vendor risk and the cost to leave.
How do you reduce vendor lock-in when buying software?
Test data export before you sign, keep business logic in your own code rather than inside the vendor’s configuration, wrap the vendor behind your own interface so replacement touches one module, and avoid exposing vendor-generated identifiers to customers where you can.
Should a startup build its own billing system?
Usually not at first. Use a payment processor and its billing features until your pricing outgrows them. If your model is unusual, such as complex usage-based pricing or marketplace payouts, owning the billing logic around a bought processor often makes sense.
Facing a build vs buy call you can’t undo?
In a two-week sprint I’ll look at the options against your codebase and roadmap, give you a written recommendation, and start the work with your team.
GMT+2 · Full EU overlap · US East mornings