should we build or buy?

the old maths

until two years ago the answer was fairly simple. the saas vendor had a development team of 50 to 500 people. your company had maybe half a person. they could build the product cheaper than you, maintain it better than you, and update it faster than you. so unless you were netflix or were building your product's core ip, you bought.

that logic still holds at the bottom. but the edge has moved markedly.

it has become easier to build. that is the problem.

sources: github copilot research, standish group chaos 2024, cisq

tools like claude code, lovable and n8n have lowered the bar for who can build what. a decision-maker without a developer background can today build a prototype in an afternoon that three years ago would have required a sprint and a budget.

it is this development that makes the question dangerous in 2026. because in practice we see two mistakes repeat themselves.

those who build things they should buy. the prototype works. it solves 70 percent of the problem. then the real list begins: authentication, gdpr compliance, backup, versioning, onboarding flows, support. 70 percent turned into a maintenance project for a person who was supposed to be working on something else.

those who buy things they should build. the vendor matches 80 percent of the need. the last 20 percent get negotiated. it becomes an integration, then a customisation project, then three years of squeezing the business's unique logic into a standard solution. custom builds fail in 35 percent of cases. but customised saas solutions do not fail less often, they just become harder to part with. this is where most experience and membership businesses end up. a standard platform has a generic data model, and then season tickets, memberships and sponsors have to be bent into something that was never made for them.

"it has not become easier to build. it has become easier to build something that looks like a solution. the difference is decisive."

the right question

the classic test "is it core or commodity?" is still useful, but not precise enough in 2026. the more useful question has three parts.

the answer is rarely either or

in practice most land in a third place. you buy the layers that are commodity, ticketing system, payment solution, email platform, and build only the thin layer that ties them together into one picture of the customer. that is usually both cheaper and less risky than either extreme, because you only own the maintenance of the part no vendor can sell you.

there is also a fourth way, where a solution is built for one customer and made available to several. it shares the development cost without compromising on the data model. it is not relevant for everyone, but it should be part of the maths.

when it really makes sense to build

we recently worked through a setup for a client where the classic answer would have been to buy. the market had a solution. it covered 80 percent of the need. the price looked reasonable on paper.

but when we worked through the total costs, and considered how precisely the system had to fit the workflow, the picture changed. a tailored solution, built on modern ai tools, could solve 100 percent of the need at a fraction of the five-year saas price.

the important point: in most cases the opposite is true. it is only in the few cases where the maths really tips over that it makes sense to build.

when it makes sense to talk to us

we do not sell development hours and are not certified in a particular platform. that means we have no hidden interest in recommending one over the other.

we often say no to building, even when it is good for our own timesheet. that is the whole point of an independent commercial architect.