Build or buy – now that AI has changed the maths

AI makes it cheaper than ever to build your own systems. But cheaper to build doesn't mean it's right to build. Here's how I think about it.

Dotun Ogunkanmi · 2026-11-04 · 5 min read

For most of my career, the question of whether to build or buy had a fairly dull default answer: buy, unless you have very good reasons not to. Building your own was expensive, slow and required a development team that most companies neither had nor wanted.

That answer is no longer so obvious. Since June 2025 I have been building Nielhouse, a service for home buyers, largely on my own with AI tools such as Lovable, Cursor and Claude. Things that a few years ago would have needed a team and several months now take days. That changes the maths. But not in the way many people think.

When building was the expensive option

In an earlier role I joined a group that, a few years before, had acquired a tech company to build its own transport planning platform. The idea was sound: a platform of its own would give the group an edge that standard systems couldn't. But the years went by, the team was pulled into everything else the business needed, and nobody had really worked out how much remained before the platform could actually carry the business.

When I did that calculation – which skills were needed, how many people and how much time – the cost of finishing the build came out at roughly the same level as procuring and implementing a standard solution. The difference was that the standard solution could be in place much sooner. My recommendation was to stop building in-house, and an external second opinion reached the same conclusion.

The hardest part wasn't the analysis. It was letting go of what had already been invested. Money already spent is the most underestimated argument in a build-or-buy decision, and it almost always points the wrong way.

At another company, with a much smaller IT organisation, there was no development team to lean on. There we had to be creative: low-code, automation in tools such as Make and – quite early on – language models to analyse data. It was often both faster and cheaper than building or buying big. I'll come back to that in a separate article.

What AI has actually changed

The biggest shift is that the cost of testing an idea has collapsed. With AI tools you can have a working prototype in a few days, let real users try it, and throw it away if it doesn't hold up.

It also makes it possible to change direction quickly. When I started Nielhouse, I wanted home buyers to be able to describe their life – what they like, which neighbourhoods suit them, what matters in their day-to-day – and be matched with homes that fit. I quickly hit dead ends. It was hard to get homes onto the platform, and hard to translate what buyers really want into something a service can work with. So I changed course and turned the service into a notebook for the home search that you can share with a partner or family. That idea wasn't bad, but it solved only a small part of what makes buying a home difficult. Each of those turns took days, not months.

But you can go wrong just as fast. You can spend days or weeks down a rabbit hole before realising that what you built wasn't needed. You can burn money on credits and tools at a pace that surprises you. It is still cheaper than a full-time developer – but it isn't free, and it isn't risk-free.

What AI hasn't changed

Building is the small part. Owning it is the big part. A solution has to be updated, secured, integrated with new systems and understood by someone three years from now. AI tools have made writing code cheaper, but not owning it.

The "we're unique" trap has become more dangerous. It has always been easy for a company to say that its needs are special. With AI tools it is also easy to build something in a few days that seems to prove it. But if someone else can easily do the same thing, it isn't unique. Something is truly unique only when it decides whether the business survives or grows.

Your vendor can often solve it for you. Sometimes the wisest move is a clear conversation with your system vendor about why a feature matters. If it matters to you, it often matters to more of their customers – and then they build it, and you don't have to maintain it.

My rule of thumb

If a solution is best maintained by a company that does the same thing for many customers, and it isn't too expensive, you are almost always better off buying.

If, on the other hand, you can't find anything that solves your particular need, it may be worth building – and then AI tools are a real option, even for smaller organisations. But only if you can also answer how the solution will be maintained.

Five questions before you decide

1. Does this decide whether we survive or grow – or is it just something we have got used to doing our own way?
2. Is there a standard solution that covers most of it, and can we live with the rest or get the vendor to build it?
3. Who maintains the solution three years from now, and who is responsible for its security?
4. Have we counted the full cost – not just building it, but running it, developing it further and one day retiring it?
5. Would we make the same decision if we hadn't already invested anything?

Cheaper isn't the same as right

AI has made it possible for more people to build. That doesn't mean more people should build – it means the decision needs more discipline, not less. Enthusiasm for what can be done must not replace the question of what is worth owning.

In the next part of this series I write about vibecoding in practice: how to stay anchored to the customer and the original plan when development moves so fast that ideas can branch several times in a single day.