Every argument for off-the-shelf software has always rested on one number: the cost of the alternative. Nobody bought a platform because it matched how their business worked. They bought it because a team that could build the matching thing cost more than living with the mismatch.
That was a reasonable trade. It is also the trade that has moved.
The mismatch was never free
The cost of a system that nearly fits is real, it is just distributed. It shows up as the spreadsheet that sits between two modules because neither will do the step in the middle. It shows up as the person whose job is to re-enter the same order in a second system. It shows up as the process that got redesigned around a screen, and then stayed that way for nine years after anyone remembered why.
None of that appears on the invoice. It appears in headcount, in cycle time, and in the quiet erosion of trust in the tools, which is the expensive one, because a team that does not trust the system starts keeping its own records, and now you have two sources of truth and no reconciliation.
When we map a workflow before a build, the finding is almost never “you need more software”. It is that six steps exist to compensate for one tool’s assumptions, and deleting them is worth more than anything we could add.
What actually got cheaper
The interesting change is not that AI writes code. It is that the fixed overhead of a serious build has come down: scaffolding, migrations, test coverage, the fourth integration adapter, the documentation nobody wanted to write. That work was never the hard part intellectually, but it was most of the calendar, and calendar is what made building to fit a luxury purchase.
What has not changed is the part that decides whether the project works: knowing which six steps to delete, what the data model has to survive, where the authorisation boundary sits, and which edge case in the pricing rules will produce a wrong invoice in month four. That is judgement, it is slow, and it is the part of a build that no amount of extra hands makes faster.
So the shape of the economics inverted. It used to be that scoping was cheap and building was expensive, which is why so much software was scoped badly and built at length. Now building is the cheaper half, and getting the scope right is the part worth spending on.
What that means for how you buy
The comparison is usually presented as two options with a sensible middle. It is more honest as three, compared on the things that actually diverge:
| Buy and adapt to it | Buy and configure | Build to the workflow | |
|---|---|---|---|
| What you are buying | A product, and its assumptions | A product, plus a project | A project |
| Where the fit comes from | Your process changes | Custom fields, scripts, chained workflows | The software |
| Cost visibility | High, it is the licence | Low, the overrun lives in what the vendor did not anticipate | Medium, a budget argued for up front |
| When the process changes | Wait for the roadmap | Re-do the configuration | Change the code |
| Ceiling | The vendor’s | The vendor’s, discovered later | A budget, which is visible |
| Who can maintain it | Anyone who knows the product | Whoever wrote the configuration | Any competent engineer, if handover was real |
The middle column is the one that gets misread. Configuration is priced as setup and behaves like a build. It has authors, bugs and upgrade risk, but no version control worth the name and no way to test it outside production.
Two practical consequences.
The first is that “we will configure the platform to fit” deserves more scrutiny than it used to. Configuration is a build. It just has a worse debugger, no version control worth the name, and a ceiling you discover after you have committed. If the answer to a workflow question is a three-month configuration project, you are already building. You are simply building on someone else’s assumptions.
The second is that fixed-price work became more honest. A fixed fee against a written scope is only fair when the estimate can be trusted, and estimates get better when the uncertain part is the thinking rather than the typing. We quote fixed fees per milestone for that reason, not as a sales position. If we have understood the workflow, the build is the predictable half.
The part that has not changed
None of the above makes custom software the right answer by default. Buy the ledger. Buy payroll. Buy anything where being identical to everyone else is the point, because the audit expects the standard shape and your version of it is not a differentiator.
Build where the workflow is the thing you are actually good at. That is the part no vendor modelled, because no vendor could, and it is now the part you can afford to have fit properly.