“Should we buy something off the shelf or build it?” is the biggest software question a mid-size company asks, and it usually gets decided by whoever sounds most certain in the meeting.
It deserves better than that. Here’s an approach that takes about an hour and gives you an answer you can defend.
First, throw out the two lazy answers
“Always buy — building is expensive and risky.” True for anything that isn’t specific to you. Nobody should build their own accounting system, email, or payroll. It’s also how companies end up with eleven subscriptions that don’t talk to each other and a person whose full-time job is moving data between them.
“Always build — off-the-shelf never fits.” Usually said by someone who enjoys building. Every system you build is a system you look after forever.
The real answer is almost always: buy the standard stuff, build the parts that connect it and the parts that are genuinely yours.
The four questions
Run the process you’re thinking about through these. Answer honestly, in writing.
1. Is this something that sets you apart, or just something you have to do? Does the way you do this have anything to do with why customers pick you? Your pick-and-pack sequence, your pricing rules, your customer onboarding might. Your general ledger doesn’t.
2. How much would you have to change to fit the product? Get specific. Not “some setup” — list the actual steps your team would do differently. If that list is more than three steps and includes one your customers would notice, that’s a real cost.
3. Does it need to touch systems you already run? Count them. A tool that lives on its own island can be bought cheaply. A tool that has to read from your ERP and write to your store already needs custom work, and the question becomes whether you’re buying a product plus that work, or just building one thing.
4. What is the workaround costing you today? Hours a week, mistakes, and how many people know how it works. If the answer is “twenty hours and one person,” the way things are now isn’t free and shouldn’t be scored as if it were.
The scoring table
| Signal | Points to BUY | Points to BUILD |
|---|---|---|
| Standard business function (payroll, accounts, email, basic CRM) | Strong buy | — |
| It’s part of how you compete | — | Strong build |
| A product fits with no change to how you work | Strong buy | — |
| You’d change 3+ steps to fit the product | — | Build |
| Only one system involved | Buy | — |
| Has to read or write 2+ systems you already run | — | Build the connection at least |
| Requirements are steady and standard for the industry | Buy | — |
| Requirements change as your business does | — | Build |
| Under about 5 users, occasional use | Strong buy | — |
| A team using it daily, all day | — | Build is defensible |
| Nobody does this by hand today | Buy | — |
| Somebody spends 10+ hrs/week on the workaround | — | Build |
| You have nobody to look after software | Strong buy | — |
| A vendor would hold data you must control | — | Build |
Add up each column. A clear majority is your answer. A tie usually means the honest answer is a third option.
The third option, which is usually right
Buy the platform. Build the fit.
Keep the commercial system you already pay for — the ERP, the store, the accounting package — and build the thin layer that makes it work the way your business works. That layer is small, it’s genuinely yours, and it’s where nearly all the value is.
In practice that looks like: a scan station that writes into your existing ERP and signs people in against the staff list that’s already there, so there’s no second list to keep up. A service that works out your true sellable stock and pushes it to your store. A one-screen tool that replaces the six-system copy-and-paste job of adding a product. None of these replace a platform. All of them remove a person-shaped gap between platforms.
Three costs people forget, on both sides
Buying has a build cost. Moving your data over, connecting it up, training, and the process changes you swore you wouldn’t make. Budget it as real money.
Building has a running cost. Hosting, updates, and someone who can change it in two years. Ask whoever builds it — in-house or outside — what happens when you need a change and they’re not available. If there’s no good answer, the price is wrong.
Both have an exit cost. With a vendor, ask how you get your data out and what that costs. With custom work, ask who owns the code and whether another developer could pick it up. “You own the code, it runs in Docker, the database changes are plain SQL” is a real answer. “It’s on our platform” isn’t.
The one-hour version
Write the process down on a page. Time the current workaround. Answer the four questions. Fill in the table. If it says buy, buy it without guilt. If it says build, scope the smallest version that removes the pain — one workflow, not a platform — and ship that first.
The companies that get this right are rarely the ones with the strongest opinion. They’re the ones who wrote it down.