Buy, Build, or Both: Choosing Software Without Regretting It
Buy where your process is ordinary. Build where your process is the reason customers choose you. The expensive mistake is doing the opposite.
Every growing organisation reaches the same fork. The spreadsheet has stopped coping. Somebody suggests a product. Somebody else suggests building exactly what is needed. Both are defensible and both go badly wrong in predictable ways, so it is worth having a rule.
The rule is this: buy where your process is ordinary, build where your process is your advantage.
Most of what you do is ordinary, and that is good news
Payroll is not a differentiator. Neither is accounting, email, calendars, or storing documents. Your approach to them may be perfectly sensible, but no customer chose you because of it, and no competitor is losing sleep over it.
For everything in that category, buy. You are purchasing not just the software but a roadmap, a support contract, compliance work, security patching, and the accumulated experience of a vendor who has seen thousands of organisations do this. Recreating that internally means funding all of it forever, in exchange for a system that does the same job with fewer eyes on it.
The tell is simple: if you can describe the requirement without mentioning anything specific about your company, buy it.
Some of what you do is the reason you exist
Then there is the other kind. The way you price a job. The logic in how you allocate stock across locations. The sequence your operations team follows that makes your delivery reliable when competitors' isn't. The specific shape of the relationship you keep with your customers.
That is not a feature request. That is the business. When you force it into a generic product, one of two things happens: you contort the product until it half-fits and becomes fragile, or you contort the business until it fits the product- and quietly surrender the thing that made you distinctive.
Build there. Not because building is superior, but because that logic is an asset you should own.
The trap in the middle
The most costly outcome is neither pure buy nor pure build. It is buying a platform and then customising it so extensively that it becomes bespoke software with none of bespoke software's advantages.
You inherit the vendor's constraints, their release schedule, their data model, and their pricing- plus a customisation layer that only one consultant understands, which breaks on upgrade, and which now blocks you from upgrading. Organisations get stranded on versions years out of date for exactly this reason.
A useful threshold: if configuration is turning into development, stop and re-decide. Configuring within intended limits is fine. Writing substantial code inside someone else's platform to make it behave like a different platform is a signal, not a milestone.
The answer is usually "both", deliberately
The healthiest architecture in most mid-sized organisations is a bought core with built edges. Use the established product for accounting, HR, and email. Build the customer-facing experience, the operational tooling, and the internal workflow that reflects how you actually work. Connect them with APIs and integration, so data moves once and lives in one authoritative place.
This requires something both extremes let you avoid: deciding, per system, which one holds the truth. Two systems that both believe they own the customer record will disagree, and reconciling them by hand becomes somebody's permanent job.
Make that decision explicitly, early, and write it down. It is worth more than the build-versus-buy argument itself.
