The Cost of Being Different Just Fell. The Cost of Being the Same Did Not.

For about twenty years, the sensible default in enterprise technology was straightforward: buy anything that is not a core differentiator. Writing software was slow and expensive, so you paid a vendor for everything you could and reserved engineering effort for the handful of things that genuinely made you money.

That default was correct for a long time. Half of it just stopped being correct, and the half that changed is not the half most people assume.

Two kinds of expensive

Software gets expensive for two quite different reasons, and conflating them is what makes the current moment confusing.

The first reason is the writing itself. Volume of logic, number of screens, breadth of rules. This is where effort goes in workflow systems, internal tooling and orchestration — the code that decides what happens next, who approves it, what escalates, how exceptions get routed.

The second reason has nothing to do with writing. It is regulatory surface, accumulated edge cases, certification, and liability when you get it wrong. This is where the cost lives in a general ledger, a payroll engine or a regulated reporting system. Most of what you pay for there is twenty years of somebody else discovering, painfully, what the exceptions are.

AI-assisted development collapsed the first kind of cost substantially. It did essentially nothing to the second. And vendor licence pricing, in both categories, has barely moved.

What follows from that

Take the workflow layer over a three-year horizon.

The cost of buying is not just the licence. It is the licence, plus implementation, plus the consultancy required to make a general-purpose engine express your specific rules, plus repeating that consultancy every time the business changes, plus the permanent constraint that you can only express rules the platform anticipated.

The cost of building is a much smaller engineering effort than it was three years ago, plus maintenance, plus the genuine responsibility of owning something.

For an organisation whose way of working is actually its own, that comparison now often favours building. In 2022 that would have been an eccentric position. Today it is unremarkable, and roadmaps written before 2025 are quietly pointing in the wrong direction.

Run the same comparison on the ledger and nothing changes. Build a payroll engine because coding got faster and you will discover, expensively, that the fast part was never the expensive part.

The layer where the answer is neither

There is a third category worth naming: the intelligence layer — retrieval, models, agents.

Here the mistake is neither building nor buying. It is committing. Model capability improves faster than any contract term, so a multi-year commitment to a vendor's embedded AI is functionally a commitment to whatever that vendor's capability looked like on signing day.

The durable approach is to own the parts that persist and rent the part that changes. Keep retrieval, prompt construction and agent logic in your own codebase. Put model providers behind an interface. Maintain a test set of real tasks so you can actually tell whether swapping one for another made things worse.

The subtle trap is retrieval. Managed retrieval services are appealing because they remove real work, but retrieval determines answer quality more than model choice does, and embeddings do not transfer between providers. Hand it over and the model decision becomes permanent no matter how clean the rest of your abstraction is.

The short version

Buy the parts where being the same as everyone else is perfectly fine. Build the parts where being different is the entire point — because the cost of being different fell sharply, and the cost of being the same did not move at all.

And in the layer that is still changing every few months, commit to an architecture rather than to a vendor.

Frequently Asked Questions

Why did AI change build-versus-buy unevenly?

Because it reduced the cost of writing logic but not the cost of regulatory surface, accumulated edge cases and liability. Workflow systems are dominated by the first; ledgers and payroll engines by the second.

Should companies now build their own ERP or payroll system?

No. The expense in those systems was never mainly development. It is regulation, certification and twenty years of edge cases already absorbed by an incumbent, none of which faster coding addresses.

When does building workflow logic make sense?

When your process is genuinely distinctive and that difference is why customers choose you, or when configuring a bought platform would require continuous consultancy. If the process is standard, buying still wins.

What is the mistake in the AI layer?

Committing to a provider rather than an architecture. Capability improves faster than contract terms, so multi-year commitments lock you to a snapshot that ages quickly.

Why is retrieval the main lock-in risk?

Because it influences answer quality more than model selection does, and embeddings are not portable between providers. A managed index makes the model choice effectively permanent.

How can you tell a bought platform is the wrong fit?

Count the spreadsheets maintained alongside it. Three or more, with one treated as more authoritative than the system, means it cannot express how the business actually works.

---

Full version with the complete four-layer breakdown: https://techcirkle.com/blog/digital-transformation-software

TechCirkle builds custom software where it pays: https://techcirkle.com/development/custom-software-development