The question usually arrives already decided. Someone has sat through four demos, none of them fit, and the conclusion forms on its own: we'll have to build something.
Almost always, that's the wrong conclusion drawn from the right evidence. The demos didn't fit because demos never fit. They're built to show a clean version of a business that doesn't exist.
Start from the honest default: buy
Most software categories are well served — inventory, CRM, content management, accounting, the systems that run the day to day. These are solved problems, solved repeatedly, by companies who've seen more businesses like yours than you or we ever will.
A good platform, configured properly, beats a custom build on cost, on risk, and on the thing nobody costs at the start: who maintains it in five years when the person who wrote it has moved on.
So the default is buy. The interesting question isn't build or buy — it's where the platform stops.
"No platform fits our process" is true of every business and is not, by itself, an argument for building. The question is whether the parts that don't fit are the parts that make you money.
Where the platform actually stops
In our experience it stops in the same three places, and none of them requires replacing the platform.
The edges of your process
The rule your largest customer negotiated in 2019 that exists in no product's data model. Real, valuable, and nobody's roadmap.
The handoffs
Your logistics provider, your marketplaces, your finance system. The platform speaks none of their dialects out of the box.
The thing you're actually good at
If your process is genuinely your advantage, no vendor has productised it — because if they had, it wouldn't be an advantage.
Notice that all three are edges. None of them is the core of what the software does. The centre of the platform is fine. It's the perimeter that needs work, and the perimeter is a fraction of the surface area of a full build.
The test we actually apply
Before anything gets built, one question decides it:
Is this process the reason customers choose you, or is it just how you happen to do it?
If it's how you happen to do it, change the process and take the platform's version. That sounds like a compromise and it's usually a bargain — you're trading a habit for a system somebody else maintains forever.
If it's genuinely why customers choose you, build that part. Only that part. Integrate it to the platform running everything else.
A useful reframe: you're not choosing between a platform and a custom system. You're choosing which 5% to build. Teams that skip this question tend to build 100% of something a vendor would have given them for a licence fee.
What "buy, then extend" looks like
One example, in distribution. An Australian confectionery distributor came to us running the business on one system and a wall of spreadsheets. The temptation — the one the demos had created — was to build something that finally matched how they worked.
We reviewed the options independently and landed on the platform that fitted, an inventory and order system called Cin7. Then we built the part no platform reaches: custom APIs and middleware connecting their third-party warehouse and logistics provider, and automating customer ordering into it.
Forty per cent of the spreadsheets were retired into the single system. Orders now reach the 3PL through an API rather than an inbox, and are processed the same day.
The platform was a decision. The integrations were the work. That ratio holds across most categories, not just distribution.
(Disclosure: our sister brand MyWebTeam has since partnered with Cin7. This selection predates that partnership — the recommendation came first.)
When building really is the answer
It happens. Usually when:
- The process genuinely is the competitive advantage, and productising it is the business
- The category is too specific for anyone to have served it properly
- Every platform assessed fails on the same requirement, and that requirement is non-negotiable
- You've already bought twice, and both times the gap was the same gap
That last one is worth sitting with. Two failed implementations is evidence about the requirement, not about the vendors — which is its own problem, with its own tell.
The expensive version of getting this wrong
The costly mistake isn't picking the wrong platform. It's discovering in month eight that the process everyone actually uses was never in scope — because it lived in a spreadsheet nobody mentioned during discovery, and the spreadsheet was doing something the real system can't.
That's why we start with the spreadsheets. They hold the requirements. A specification holds what people think the requirements are.
Where to start
If you're weighing this decision, the sequence that works is unglamorous: map how the business actually runs, assess the realistic options against that rather than against a feature list, and get the recommendation in writing with the trade-offs made explicit — from someone who isn't selling you the software.
Bring the spreadsheets. They'll tell us more than a specification will.
Frequently asked questions
Buy, unless you have a specific reason not to. Most categories — inventory, CRM, content management, accounting — are solved problems. A good platform, configured properly, beats a custom build on cost, on risk, and on who maintains it in five years. The real question isn't build or buy; it's where the platform stops and what you extend it with.
Apply one test: is this process the reason customers choose you, or just how you happen to do it? If it's how you happen to do it, take the platform's version and change the process. If it's genuinely your competitive advantage, build that part — and only that part.
Almost never, once you count maintenance. The licence is visible and easy to attack; the cost of owning a codebase for a decade — including the year after its author leaves — usually isn't costed at all. Custom work pays off at the edges, not at the core.
The edges: the integrations to your logistics, marketplaces and finance systems, and the one process that's genuinely your advantage. That's typically a small fraction of the surface area of a full build — and it's the fraction no vendor's roadmap will ever reach.
Work out which 5% to build
An independent review of the options in front of you — from someone with no licence to sell.
Related reading
- Software Review & Implementation — the independent assessment behind this decision
- How to choose business software without getting sold to — the question every time
- Why the second implementation fails the same way as the first — when you've already bought twice
- The ERP worked — for the people who chose it — what one big system costs the teams who didn't choose it
- Wholesale & Distribution — what this looks like in distribution