Most companies make the build-vs-buy decision wrong twice — they buy when they should build, and build when they should buy. Here are the five questions that get you closer to the right answer.
The pattern we see most often: a company buys a CRM because "everyone uses Salesforce," then spends 18 months building plugins to make it work like their custom sales process. Or, the inverse: a company builds its own auth system because "it's just a login form," then gets owned in production six months later because they didn't understand session fixation.
Both are expensive. Both are avoidable with five honest questions.
1. Is this our actual differentiator?
If your competitive advantage is "we do X better than anyone," you build X. If X is everything you can do but it's not the thing customers come back for, you buy X.
An e-commerce company's differentiator is usually the catalog and the customer experience. Their payment processing isn't — Stripe, Adyen, or Mollie do that better. They should buy payments and build catalog.
An insurance company's differentiator is usually underwriting and claims. The HR system isn't. Buy the HR system. Build the underwriting engine.
The test: if you swapped this component for a generic third-party version overnight, would your customers notice? If yes, build. If no, buy.
2. What's the real maintenance cost?
The build estimate is always wrong on the low side, because people forget that "build" means "build and operate forever." A custom system you wrote in 2024 needs:
- Security patching as new vulnerabilities emerge.
- Dependency updates (every 6-12 months, more if you picked a fast-moving stack).
- OS and runtime upgrades.
- Documentation that actually stays current with the code.
- Onboarding for every new team member who has to work with it.
- An on-call rotation.
A reasonable estimate: ongoing maintenance costs roughly 15-25% of the original build cost per year. So a €200k custom CRM costs you €30-50k per year just to keep alive. If a SaaS CRM at €2,000/month delivers 80% of what you need, the SaaS is dramatically cheaper for ten years.
3. How much does the third-party constrain us?
Buying isn't free either. Every third-party tool comes with constraints:
- Data model constraints. The vendor's idea of a "customer" might not match yours.
- API rate limits. If you need to read or write a lot of data, this can become the bottleneck.
- Pricing model risk. SaaS vendors get acquired and re-price. Plan for the day Salesforce buys your favorite niche tool and triples the price.
- Integration tax. Every integration is an ongoing maintenance burden, especially when the vendor changes their API.
The test: if the vendor doubled their price tomorrow, what would you do? If your answer is "switch in 30 days," you have leverage. If your answer is "we'd have to rebuild three years of work," you don't.
4. What's the integration tax?
The cheapest "buy" decision in slides is the most expensive in production. Every system you buy has to talk to every other system you buy. Five SaaS tools is ten integrations (each pair). Ten SaaS tools is forty-five.
The integration tax shows up as:
- Sync jobs that fail silently and corrupt your data.
- Identity confusion ("which system is the source of truth for this customer?").
- Bespoke ETL pipelines that nobody can debug.
- Reporting that requires combining three exports manually.
If you're integrating two tools, fine. If you're integrating ten, you've effectively built a custom system out of someone else's components — but you don't own any of the pieces. Sometimes the right move is to consolidate down to one tool that does 70% of everything, even if it's not best-in-class for any one job.
5. Could we do this in 6 months and stop?
The strongest case for "build" is when the scope is genuinely small and bounded. The strongest case for "buy" is when the scope keeps growing.
If you're building "a simple admin dashboard" and you've been building it for 18 months, you didn't pick the right scope. Go buy Retool, Forest Admin, or React Admin and stop fighting.
If you can describe what you're building in three sentences, agree on the scope, and ship it in 4-6 months without scope creep, building is fine. If three teams disagree on what the system should do, no amount of building will save you — buy something that has opinions baked in.
Our default bias
For our clients, the default is buy. Build the things that are core. Buy everything else, even if the buy option is 70% of what you wanted. The 30% you give up by buying is almost always cheaper than the 100% you take on by building.
The exceptions:
- Your differentiator (build it, own it, never compromise).
- Things where compliance/regulation makes the SaaS option unviable.
- Things where the scope genuinely is small and bounded.
For everything else, the boring answer is the right one: someone has already built this, they probably know more about it than you, and you should pay them.
What you can take from this
Before your next "should we build this?" meeting, write down the answers to these five questions on one page. If three or more of them point to "buy," buy. If three or more point to "build," build. If they're split, you probably haven't scoped the problem yet — go scope first.
And if you're stuck on any of them, that's exactly the kind of conversation we have with clients in our discovery sessions. Tell us about it.