"Should we build it custom or buy off-the-shelf?" is the most common question we get from new customers. The honest answer is: it depends on five things — and almost every case where someone got it badly wrong, they didn't actually go through them.
Here's the framework we use with customers — including the disqualifying answers that mean we'll recommend you go the other direction, even when it costs us the engagement.
The vendor bias problem
When you ask a software vendor "should we build or buy?", they will almost always tell you to build. When you ask a SaaS vendor the same question, they will almost always tell you to buy. Both are operating in good faith — and both are wrong about half the time.
This is why frameworks matter. A clear set of questions, asked in the same order, with the same disqualifying answers — that's how you get an answer that doesn't depend on which company is in the room.
The five-question test
For each candidate workstream — say, "your finance system" or "your customer onboarding flow" — answer these five in order. Stop the moment you hit a disqualifying answer.
1. Is your process meaningfully different from the median customer of the leading off-the-shelf product?
If the answer is "no, ours is pretty standard" — buy. The leading off-the-shelf product captures the median process, and the median is fine for you. Don't pay to rebuild it.
If the answer is "yes, our process is genuinely unusual because [specific structural reason]" — keep going.
2. Is the process a competitive differentiator, or just a cost centre?
If it's a cost centre — payroll, statutory reporting, leave management, the office expense system — buy. Even if the off-the-shelf product is a 70% fit, the missing 30% is rarely worth a 5x price tag.
If it's a meaningful differentiator that customers feel — your underwriting model, your dispatch optimisation, your service-quality scoring, your customer onboarding flow — keep going.
3. Is the off-the-shelf product extensible enough to absorb your differentiation?
Modern SaaS products are surprisingly good at this. If the platform exposes a real API, supports custom fields and scripted automations, and has a track record of customers building unusual things on top — buy and extend.
If extending it means writing brittle workarounds, hard-coded integrations, and shadow systems that drift away from the platform — keep going.
4. Will the workflow still be unusual in five years?
This is the question most teams skip. Some processes are different today because of historical accident; in five years, market norms will catch up and the off-the-shelf products will support what you do natively. If that's the case — buy, and accept some short-term friction.
If the difference is structural, anchored in your industry, customer base, or regulatory environment — and likely to remain so — keep going.
5. Do you have the operating capability to own a custom system long-term?
This is the killer question. Custom software is a perpetual commitment. You'll need engineers (in-house or with a partner) for the next decade — to extend it, secure it, modernise it, and eventually retire it. If your organisation can't credibly commit to that — buy. A custom system you can't maintain is worse than an off-the-shelf one you don't love.
If you can credibly commit — build.
The build-vs-buy decision isn't really about software. It's about whether you can credibly own and operate a system for ten years. Most "we should build it" conversations end the moment we ask that out loud.— Mohamud Ali, CEO
When the answer is buy
Buying isn't surrendering — it's prioritising. When the answer to question 1, 2, 3, or 4 is the disqualifying one, buy with conviction. Pick a credible vendor, commit to their model, train your team, and stop second-guessing.
- Optimise for fit, not features. The product that does what you need is better than the product with the longer feature list.
- Pay attention to support quality. You will live with this vendor's support team for years. Reference-check it.
- Negotiate exit. Data export, schema documentation, and migration support — get them in writing before you sign.
When the answer is build
Building is a serious commitment. If you're going to do it, do it well — with a partner who'll still be answering the phone in five years and code that the next team can maintain.
Custom software only pays off when you treat it like a product, not a project. That means a roadmap, an owner, and a budget for ongoing iteration — not a one-time build that gets archived after launch.
The hybrid play
Often the right answer isn't "all custom" or "all off-the-shelf" — it's a thoughtful mix. Buy the commodity layers (HR, accounting, identity); build the differentiating layers (your underwriting model, your dispatcher, your customer-facing journey). Stitch them together with deliberate integration architecture.
This is what most of our customers actually end up with — and the right places to draw the lines are different for every business.
A cleaner way to decide
The strongest signal that you're answering the build-vs-buy question well is that the conversation gets shorter, not longer. A clear framework produces a clear answer, fast.
If you've been in build-vs-buy debates that have lasted six months, that's not a hard problem — it's an unstructured one. Run the five questions. Stop at the first disqualifier. Commit to the answer. Move on.