We build custom software, so we have an obvious interest in this question, and the useful thing we can offer is where the line genuinely falls rather than an argument that it falls in our favour. In practice we tell prospective clients to buy more often than they expect.
The framing that causes trouble is treating this as a single decision about a whole system. Almost nobody should build their own general ledger, and almost nobody should run their differentiating operational workflow on a product designed for a different industry. The real question is where, in your particular operation, the boundary between those two sits.
Start from what makes you different
A useful first pass: for each system, ask whether a customer would ever notice if you did it exactly the way everyone else does. Payroll, no. The way you price a complex job, schedule around technician certifications, or handle a partial delivery, quite possibly yes.
| Category | Default | Reasoning |
|---|---|---|
| Accounting, payroll, tax | Buy | Regulated, commoditized, and someone else absorbs the cost of every rule change. |
| Email, documents, communication | Buy | No plausible advantage and an enormous amount of undifferentiated work. |
| CRM, at baseline | Buy | Contact and pipeline management is ordinary until it is genuinely tied to your operations. |
| Reporting and BI | Buy the tool | Buy the visualization layer, but own the data model underneath it. |
| Core operational workflow | Build | Dispatch, job lifecycle, and pricing are where the business actually differs. |
| Integration between systems | Build or configure | Nobody sells the connection between your specific systems and your specific rules. |
| Customer-facing portals | Usually build | This is your product surface, and generic portals feel generic to the customer. |
These are defaults rather than rules. A company whose entire competitive position is unusual cost accounting might reasonably build there, and a company whose dispatch really is ordinary should absolutely buy it.
The fit test, done properly
Product evaluations usually fail the same way. The demo covers the normal case, the normal case works, and everyone is reassured. The normal case was never the problem. What matters is the awkward five per cent of your work that generates most of the exceptions and most of the manual effort.
- 1
Write down the ten most awkward real situations from the last quarter, using actual records rather than hypotheticals.
- 2
Include the ones staff describe with a sentence beginning 'well, normally, but'. Those sentences are where your process actually lives.
- 3
Ask each vendor to demonstrate those ten specifically, in their product, rather than describing how it could be configured.
- 4
Note which ones require customization, which require a workaround, and which require changing how the business operates.
- 5
Decide honestly which of those process changes you are actually willing to make, because a process change accepted in a meeting and rejected by staff in week three is a failed implementation.
The customization trap
There is a third path that presents itself as the sensible middle: buy the platform and customize it heavily to fit. Sometimes this genuinely works. Often it produces the worst available economics, and it is worth understanding why before you choose it.
- You pay the license and the build cost, rather than one or the other.
- Every platform upgrade becomes a regression test of your customizations, and eventually the upgrade gets deferred, which is how installations become frozen and unsupported.
- The customization is written in the vendor's proprietary extension model, so the skills are scarce and expensive and the code does not transfer anywhere.
- You inherit the platform's data model, which was designed for a different business, and every subsequent change has to be expressed in its vocabulary rather than yours.
- Support conversations become an argument about whether the fault is in the product or in your extensions.
The heuristic we use: light configuration is buying, and heavy customization is building with a permanent tax attached. If the fit test showed that most of your awkward cases need extension work, you are already in a build. The only question left is whether you want to do it inside somebody else's constraints.
Comparing the actual cost
Most build-versus-buy comparisons are unfair in the same direction: they compare a build quote against year one of a subscription. Compare five years, and put the costs both sides tend to omit into the same table.
| Buying | Building |
|---|---|
| Subscription, at projected headcount rather than today's | Initial build cost |
| Implementation and data migration | Data migration |
| Customization and ongoing extension maintenance | Ongoing maintenance and dependency updates |
| Integration to your other systems | Integration to your other systems |
| Annual price increases and tier changes | Hosting and infrastructure |
| Training, and retraining after vendor UI changes | Training |
| The workarounds staff build around a partial fit | The cost of being wrong about a requirement |
| Exit cost if you leave, including data extraction | Ownership of the asset at year five |
Two lines in that table decide most comparisons. Per-seat cost against headcount growth is the one buyers underestimate, because the comparison is usually made when the user count is at its smallest. The workarounds line is the one nobody costs at all, and it is frequently the largest number on the page: if forty people each lose twenty minutes a day to a re-keying step the product cannot avoid, that is a full-time salary, every year, invisible in the budget.
The bridge, when the deadline is the constraint
Occasionally the honest answer is build, and the calendar does not allow it. A renewal is due, or a contract requires a capability next quarter. In that case a deliberate bridge is a legitimate strategy rather than a failure.
We have done this: on a trades services engagement a no-code stack carried job management, dispatch, field capture and invoicing within about six weeks, which beat a NetSuite renewal the client then declined. The bridge ran while the permanent platform was designed around how the work actually happened, observed rather than specified. What makes that work rather than becoming a second patchwork is deciding the exit condition before you build it.
Common questions
- Is building always more expensive up front?
- Usually yes, and that is the correct expectation. The comparison that matters is total cost over the life of the system, including per-seat growth, integration, customization maintenance, and the labour absorbed by workarounds. Buying frequently wins that comparison too. The point of doing the arithmetic is that it is not obvious in either direction until you have.
- What if no product fits but building feels too risky?
- Reduce the scope rather than the ambition. Build the one workflow where the misfit is most expensive, leave everything else on the products you already run, and integrate between them. This is far less risky than a whole-system replacement, it produces value in months, and it lets you stop after any increment if the value is not there.
- How do we know if our process is genuinely unusual?
- Be sceptical of the claim, because most businesses believe their process is unique and most are wrong in the ways that matter. The honest test is the ten awkward cases: if several vendors can demonstrate them convincingly on your data, your process is ordinary and you should buy. If none of them can without a customization project, that is evidence rather than pride.
- Can we start with a product and build later?
- Yes, and it is often the sensible sequence, provided you keep your data extractable and understand the exit cost before you are dependent. The mistake is not starting with a product. It is arriving at year four with data you cannot get out, business rules that exist only inside the vendor's configuration, and no plan that was ever written down.
- Where do you tell people not to hire you?
- When the requirement is ordinary, when a well-established product covers the awkward cases, when the process is still changing weekly, or when the real problem is that a platform you already pay for is configured badly. Custom software earns its cost where the business is genuinely different, and pretending that is everywhere would not survive the first project.