The build-versus-buy conversation almost always has a third option in it, presented as the sensible middle: buy the platform, then configure it to fit. Lower risk than building. Faster than building. Supported by a vendor.
It is a reasonable option. It is not a third option. It is building, with a worse toolchain.
Where the line actually sits
Setup is choosing from things the vendor anticipated. Currency, tax rules, approval thresholds, which fields are required. That work is real but bounded, and it is what “configuration” means in the sales conversation.
A configuration build is different. It is when you start expressing logic the vendor did not anticipate:
- a custom field that carries meaning the platform does not understand, enforced only by a convention in someone’s head
- a script in a proprietary language, in a text box, with no version control worth the name
- two workflows chained together to fake a step the data model has no concept of
- an integration that exists to reconcile the platform’s view of an entity with the truth
Every one of those is software. It has bugs, it has an author, it needs testing and documentation, and it breaks on upgrade. The difference is that you cannot diff it, you often cannot test it outside production, and when it misbehaves the stack trace is a support ticket.
3 weeks
The configuration estimate at signing
11 weeks
What the configuration actually took
Why the estimate is always low
Not because anyone is lying. Because the estimate is made against the parts the vendor anticipated, and the overrun lives entirely in the parts they did not. Those parts are invisible until someone tries to express a real business rule and discovers the platform has no place to put it.
The tell is a specific kind of meeting, usually in week three, where the discussion turns to how the business could change its process so the tool does not have to. Sometimes that is the right answer, because plenty of processes are accidents worth abandoning. Often it is the mismatch quietly winning, and it costs adoption for years afterwards.
The ceiling
The real problem with a configuration build is not the cost. It is that you discover the ceiling after you have committed.
Custom software has no ceiling; it has a budget, which is a different constraint, and a visible one. A platform has a hard limit somewhere, defined by decisions made by people who have never seen your business. You find that limit by walking into it, and by then the migration cost is the thing keeping you there.
What we actually recommend
Buy the platform where your process is genuinely generic, and then live with it rather than bending it. The ledger, payroll, email, the CRM if your sales motion is ordinary. Configure the settings the vendor anticipated, and treat the appearance of a script text box as a warning sign rather than a feature.
Build where the workflow is the thing you are good at, the part that is actually yours. And when someone proposes a three-month configuration project, price it as the build it is, against the alternative of building something that fits. Sometimes the platform still wins that comparison. It should have to win it honestly.