should we build or buy?

ai and no-code have changed the maths for good. but not in the way most people think. the result is that many companies now build things they should have bought. and buy things they should have built.

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 its core. but the boundary has moved a long way.

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

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

that is what makes the question dangerous in 2026, because in practice we see the same two mistakes again and again.

those who build things they should buy. the prototype works. it solves 70 per cent of the problem. then the real list begins: authentication, gdpr compliance, backup, versioning, onboarding flows, support. 70 per cent has 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 per cent of the need. the last 20 per cent 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 per cent 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.

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.

1. uniqueness. how close is the solution to your unique workflow? if a vendor has built the same solution 500 times before, it is commodity. if your workflow looks different from 9 out of 10 competitors, it is worth considering building it yourself. a ticketing system is commodity, it has been built hundreds of times. the data model that ties ticket, membership and sponsor together into one customer rarely is.
2. the five-year cost. what are the total costs over five years, not in month one? 60 to 80 per cent of custom software costs lie in maintenance. at the same time, saas costs can grow 3 to 5 times when you add users, integrations or data volume.
3. who owns the risk. who carries the risk when things break? an internal build means you carry the risk yourself. saas means you depend on a vendor's roadmap. there is no right answer, there is a right answer for your situation.

the answer is rarely one or the other

in practice most end up 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 per cent 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 per cent 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.