Sooner or later every growing business has to choose a platform to run on — the system that holds inventory, or customers, or content, or the whole operation. It's an expensive decision, it's hard to reverse, and almost everyone making it is doing so for the first time.
The people who do it every day, meanwhile, all work for the vendors.
That asymmetry is the whole problem. You're making a decision once, against people who make it professionally, and every one of them is paid if the answer is yes.
The demo is not the product
Every platform demos beautifully, because the demo is built to. Clean data, the happy path, a business with no history and no exceptions. Your business has twenty years of history and is mostly exceptions.
So the demo tells you almost nothing about whether the platform fits you. It tells you the platform can do the thing it was built to show. The real question — what happens when your most awkward, most valuable, least standard scenario meets this software — is exactly what a demo is designed to avoid.
The single most useful thing you can do in an evaluation: bring your ugliest real case — the customer with the negotiated terms, the order that splits three ways, the content that doesn't fit the template — and make each vendor run that. The demo is their ground. Your edge case is yours.
Buy is usually right — but "which" and "how" are where the money is
Start from the honest default: buy. Most categories — accounting, CRM, inventory, content management — are mature and well served. A good platform, configured properly, beats a custom build on cost, on risk, and on who maintains it in five years.
But "buy" isn't the decision. Two harder questions sit underneath it:
Which one actually fits?
Not which demos best — which one survives contact with how you really work, including the parts that live in spreadsheets nobody mentions.
What has to be built around it?
No platform reaches every edge. The integrations and the few genuinely custom pieces are usually where the value — and the cost — actually sits.
Get those two right and a mid-range platform outperforms an expensive one chosen badly. Get them wrong and no licence fee saves you.
Where the platform stops
However good the software, it stops in predictable places — and none of them means the software is bad:
- The edges of your process — the rule a big customer negotiated years ago that exists in no product's data model
- The handoffs — your logistics provider, your marketplaces, your finance system, none of which the platform speaks to out of the box
- The thing you're genuinely good at — if a process is your advantage, no vendor has productised it, because if they had it wouldn't be an advantage
The centre of the platform is almost always fine. It's the perimeter that needs work — and the perimeter is a fraction of the surface area of building the whole thing yourself.
Sometimes the answer is "keep what you have"
The finding nobody selling to you will offer: a surprising amount of "our system doesn't fit" turns out to be a configuration decision made years ago by someone who's since left, or an integration that was never built and quietly pushed the work into spreadsheets.
In that case the cheapest, lowest-risk answer is to fix what you already own. You will only ever hear that from someone who isn't paid to sell you the replacement.
"None of these fit" and "keep what you have" are legitimate outcomes of an honest assessment. If the only conclusions on offer are the ones that end in a purchase, you're not being assessed — you're being sold to.
The test that decides build vs buy
For any part where the platform stops, one question decides it:
Is this the reason customers choose you, or 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 — 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, and integrate it to the platform running everything else.
Teams that skip this question tend to build all of something a vendor would have handed them for a licence fee.
Who should be in the room
One rule covers most of it: someone technical, who isn't selling you the software.
Someone who can read the integration reality, stress-test the data migration, and say "this won't do the thing you need" before the money is committed — with no stake in the answer being yes. On our engagements, where the group holds a partnership with a platform, we say so up front rather than let you discover it, because an assessment you can't trust isn't worth paying for.
That's what Software Review & Implementation is: an independent read of how your business actually works, an assessment of the realistic options against that, and a written recommendation with the trade-offs made explicit — followed by the implementation itself if you want us to run it.
Before you sign
A short checklist that survives contact with reality:
- You ran your worst real case through each option, not their demo
- You know what has to be built or integrated, and it's costed — not left as "we'll sort that later"
- Someone technical with no quota has said, in writing, that it fits
- "Keep what you have" was genuinely on the table
- You can defend the decision to the board with the reasoning written down
The most expensive software decision isn't usually the licence. It's discovering in month eight that the way everyone actually works was never in scope.