Build or Buy: When an Internal Tool Is Worth Building

Imagine you want to go on the umrah. You could buy a plane ticket. Or you could buy a plane.

Nobody would seriously consider the second option, because the answer is obvious: you want to arrive, not to run an airline. Owning the plane means pilots, fuel, maintenance, parking, insurance and a hundred problems that have nothing to do with the reason you wanted to travel.

Software decisions are the same question in disguise, but they rarely feel that obvious. When a business outgrows its spreadsheet, it reaches a fork: subscribe to software someone else built, or build its own. Building feels like control. Buying feels like settling. And a surprising number of businesses end up buying the plane.

The appeal of building your own

It's worth being honest about why building is tempting, because the reasons aren't foolish.

It feels like a perfect fit. Off-the-shelf software is designed for many businesses, so it never matches yours exactly. A custom system promises to do everything your way.

It feels like an asset. Paying a subscription every month feels like renting. Building feels like owning.

It signals capability. A company running its own platform is saying something about itself. Large organizations sometimes build partly for that reason, and it isn't always wrong.

It's easier than ever. With AI tools, a working prototype can appear in days. That makes the first step feel cheap.

All of these are real. The problem is that they describe the first day of a system's life. The cost of a system lives in all the days after.

Making and maintaining are two different problems

Building something has an end. There's a moment when it works, and you can point at it and say it's done.

Maintaining something doesn't have an end. Once a system exists, it needs:

• Servers and hosting, paid for every month, forever.

• A domain and certificates, renewed on time.

• Updates, including security updates, as the tools it's built on keep changing.

• Bug fixes, which keep appearing as people use it in ways nobody tested.

• People who understand it. Your own developers, or a partner on call. When the person who built it leaves, the knowledge often leaves with them.

Industry estimates vary, but a long-standing observation in software is that maintenance is usually the larger share of a system's lifetime cost, not the initial build. Over three years, building your own is usually the more expensive path: the build is expensive, the upkeep is expensive, and the need is often already covered by a product that exists.

Even the experts buy the engine

The games industry has a well-known example. CD Projekt Red, the studio behind The Witcher and Cyberpunk 2077, spent years developing its own engine, REDengine. In 2022 it announced that its future games would be built on Unreal Engine 5 instead.

This is one of the most technically capable studios in the world, choosing to buy the part it used to build. The reasoning was essentially about focus: the studio's advantage is making games, not maintaining an engine. Many large studios make the same call.

If a company that good at software decides the engine isn't worth owning, it's worth asking whether your booking system, membership tracker or inventory tool is.

When building goes wrong at scale

Large public projects show what happens when building your own is underestimated.

In the UK, the National Health Service's National Programme for IT, launched in 2002, set out to build a single national system for patient records. It became one of the most expensive IT failures on record. The government dismantled it in 2011, after costs estimated in the billions of pounds, with much of the promised system never delivered.

In the United States, HealthCare.gov launched in October 2013 and could barely handle traffic. On its first day, only a handful of people managed to enroll. It took months of emergency work to fix, and the final cost ran far beyond the original estimate.

These projects failed for many reasons, but a common thread is that the build was treated as the hard part, and the ongoing complexity of running a system for real people was underestimated. That same trap exists at the scale of a small business. It's just quieter.

When building goes right

The opposite story is just as instructive. Amazon Web Services came out of Amazon's own need to run a huge retail operation reliably. The company built infrastructure because it was core to its business, then realized other businesses needed the same thing, and began selling it in 2006. Building was the right call because infrastructure sat at the heart of what Amazon did.

The lesson isn't "never build". It's "build what sits at the heart of your business, and buy what sits around it".

A finance company shouldn't have to carry the weight of its own finance application if a good one exists. A gym should spend its energy on its members, not on its server. A restaurant should worry about the food, not the point-of-sale code.

So when is building worth it?

Building isn't always wrong. It's right in a specific set of situations, and they have something in common: the system touches the core of what makes the business different.

When your needs are specific, concrete and branching. Think of a large university. It could subscribe to a learning management system and a campus management platform. But its processes are interconnected in ways no single product covers, and a big institution often has the people and the budget to build. Stitching together five products that each fit partly can be worse than one system that fits fully.

When the system is your product, or sits right next to it. A company that sells software needs its own internal admin panel. Think of a minimarket. The shop floor is what customers see. The stockroom, the office and the safe are where everything else lives: the things customers should never see, and that must never be easy to steal. For a software business, the admin panel is that back room. It's where the business actually runs, where sensitive data sits, and where security matters most. That's worth building yourself, and worth building like a vault.

When off-the-shelf software forces you to bend every day. If your team spends hours each week working around a tool's limits, that's a real cost with a real number attached.

When you have a plan for the years after launch. Budget, people and a clear owner for the system once it's live.

The most common mistake: building for style

The mistake that shows up most often isn't choosing the wrong option. It's making the decision without a concrete need.

A business wants its own system because it sounds impressive, or because a competitor has one, or because the founder likes the idea of owning it. Image can be a bonus on top of a real need. It can't be the need.

Real needs are easy to recognize, because they're always concrete. They don't have to be big. A company that needs its own content dashboard to publish articles has a perfectly valid need. What makes it valid is that the purpose is clear.

When a business can't say what it needs or why, the useful question isn't "build or buy?" It's a more basic one about the business itself. A business that's actually running always runs into specific problems. If none come up, the software probably isn't the problem.

Three questions before you decide

Before choosing either path, answer these in plain language:

1. What exactly is the need? One sentence, in the language of your business, not of software.

2. How much does it get in the way today? A minor annoyance and a daily bottleneck lead to very different answers.

3. What solution are you picturing right now? This exposes the assumptions you're already carrying.

Then add a fourth: how much extra weight are you willing to carry for the next three years? Not just money. Attention, people and the risk of the system becoming a problem of its own.

The middle path

It doesn't have to be all or nothing. Many businesses do best with a hybrid: buy the core, and build around it.

Use established software for the parts every business needs, like billing, membership, accounting or email. Then build small, focused pieces on top: an integration between two tools, a dashboard that combines data from several places, a customer-facing page that matches your brand. You get the fit where it matters, and someone else carries the heavy parts.

Whether that makes sense depends, as always, on the need.

A rough three-year comparison

Numbers differ wildly by project, but the shape of the comparison is usually similar. Here's how the costs tend to fall over three years:

The build has a price you can see on day one. The years after it have prices you only see on day 400. A fair comparison puts both on the table before deciding.

Worth it, not just possible

With modern tools, almost anything can be built. That makes "can we build it?" the wrong question.

The right question is whether building it is worth it: whether what you gain in fit, control or advantage is bigger than what you'll carry in cost, maintenance and focus.

Most of the time, you just need a ticket. Buy the plane only when flying is your business.

Layerice is a software design and development studio for businesses. Sometimes the most useful thing we can tell a client is to buy instead of build.