Every growing business hits this fork: buy the packaged tool, or build something of our own? Most advice on the question is written by someone selling one of the two answers. Here is the method we use with our own consulting clients — it fits in an afternoon and produces a defensible decision.
Step 1: Write down the workflow, not the wishlist
Feature lists lie. Instead, document the five processes the software must carry — who starts them, what they touch, where they end. A packaged tool that covers four of five processes 100% beats one that covers all five at 80%, because that missing 20% is where staff return to spreadsheets and the system quietly dies.
Step 2: Score the deal-breakers
- Fit: Can the package run your five processes without workarounds? Score each 0–2.
- Change: When your process changes, who changes the software — you, a vendor, or nobody?
- Data: Can you get your data out, completely, on the day you want to leave?
- Total cost: Licences × users × years, plus implementation — compared honestly against a build quote.
- Integration: Will it talk to your accounting, hardware and existing systems?
Step 3: Price the hidden column
The costs that decide the question rarely appear in either quote: staff hours lost to workarounds, the price of per-user licensing at your five-year headcount, and the compounding value of software that adapts when your business does. Custom software carries its own hidden column — maintenance and a partner who answers — which is why who builds it matters more than what gets built.
The honest summary
Buy when your process is standard and your differentiation lies elsewhere. Build when the process is your edge, when packaged tools force workarounds, or when licence math turns brutal at scale. And if an afternoon with this scorecard doesn't produce a clear answer, that itself is an answer: get an independent assessment before committing either way.