Build or buy: how to make the software decision

It nearly always starts the same way. There is a spreadsheet that has become too important, or a tool that does eighty percent while people work around the last twenty by hand. Someone says: could we not just have something built for this?

Sometimes that is the best money you will spend. More often it is a nine-month project that ends in something that works, that nobody uses, and that you now have to maintain yourself. The difference is not the budget or the builder. It is the question that comes first.

The three routes

There are only three, and most people look at two.

	Buy	Extend	Build
What it is	Take an existing product as it comes	An existing foundation extended your way	From scratch, for you alone
When	Your process looks like everyone else's	Mostly like everyone else's, with a few steps that genuinely matter	Your process is your edge, and it exists nowhere
Live in	Days	Weeks	Months
Order of magnitude	Hundreds per month	Tens of thousands one-off, plus subscription	Six figures and up
What goes wrong	You bend your process to the tool and nobody remembers why	You ask for so many changes that you are building anyway	You build what you thought you needed in month one
Who maintains it	The supplier	The supplier	You

That middle column is the one most often skipped, and it is usually the right answer. A foundation that already stands, with the four or five things on top that are yours. You pay for the difference instead of the whole, and you inherit every improvement made to the rest.

The four questions that decide it

Work through them in this order. At the first "no" you have your answer.

1. Is this process your edge, or is it just work?

Invoicing, leave requests, time tracking: that is work. There is a product for it, and that product is better than what you would have built, because a thousand companies have shaped it. Only build what sets you apart from your competitor. If you cannot answer in one sentence, the answer is no.

2. Can you write down what it has to do without talking about screens?

Anyone who starts with "and then I want a button here" does not yet have a problem, they have an idea. If you can describe in ten lines which decision the system has to support, who makes it and where it currently goes wrong, it is sharp enough to build.

3. Will anyone use it once it exists?

This is the question that kills most custom projects and that nobody asks. Software nobody opens is more expensive than no software. Name the person who will work in it daily, and let that person decide on scope with you. If you cannot name them, do not build.

4. Who maintains it two years from now?

Custom software does not break on delivery. It breaks when the browser changes, an integration drops, or the builder starts another company. If you have no answer to this, you are buying something that becomes a problem in two years.

Where the money on a custom build actually goes

The build is the line you get quoted. The rest is the line you forget. The ratio below is what we see in practice across the first three years.

Item	Share of total cost	Usually in the quote
Building the first version	around 40%	yes
Changes once people start using it	around 25%	no
Maintenance, hosting and security	around 20%	no
Onboarding and your team's learning curve	around 15%	no

What happens in practice: you sign for the first line and budget for none of the other three. Six months in comes a request that is "not that big really", and then another. So do not only ask your builder what it costs. Ask what it costs per year to keep it alive.

From my own practice. For Upgrado, which buys, renovates and resells properties, the question came in as "we want a tool". The real question turned out to be: what is the most I can pay for this one? That answer lived in a spreadsheet rebuilt for every project, and otherwise in the owner's head. We turned the calculation around. You no longer enter a bid to see what the margin becomes. You fix your threshold and the system works back to the maximum you may offer. If a deal does not clear that threshold, the gate says so, with the reason attached. It became a small system, and it stayed small because the question was sharp before a line of code existed.

If you do build: five rules

Start with a concept phase you pay for separately. Prototype, data model, backlog, estimate. At the end you decide whether to continue, with no obligation. Skipping that step to save time means paying for it later with interest.

Work in two-week sprints with something working at the end. Not a demo, but something you can put someone in front of. A project that shows nothing for three months shows the wrong thing after three months.

Fix the scope and keep a list for the wishes. Every request that arrives during the build goes on the list, not into the sprint. At the end of each sprint you decide together what still goes in. That keeps it discussable without letting it run over.

Agree who owns the code. Not because you expect trouble, but because making that agreement afterwards is the most expensive discussion there is.

Budget for maintenance from day one. Put an amount per month in the plan, even in the months when nothing happens. Software without a maintenance budget becomes software nobody touches.

In short

Build what sets you apart and buy the rest. If you cannot say in one sentence what this system does that an existing product does not, the honest conclusion is that you should buy a product and tidy up your process. That is a duller answer and it is usually the right one.

And if you are in between, with a process that is mostly ordinary and yours on three points, look at the middle column before you start on the right.

Frequently asked questions

When is custom software the right choice?

When the process sets you apart from your competitor, you can write down in ten lines which decision the system has to support, you can name the person who will work in it daily, and you know who maintains it in two years. If one of those four is missing, buying or extending is almost always better.

What does it cost to have software built?

A serious first version starts around six figures in practice, and that is roughly forty percent of what it costs over three years. The rest goes to changes once people use it, to maintenance, hosting and security, and to getting your team live. So ask about the annual cost, not just the build.

What is the difference between custom software and extending an existing platform?

With custom software everything starts at zero and everything is yours, maintenance included. With an existing platform you pay only for the gap between what is there and what you need, and improvements to the foundation come along for free. It is the middle route that is most often skipped and most often correct.

How do I stop a software project from running over?

Pay for the concept phase separately and decide on the build only after it, work in two-week sprints with something working at the end, and put every request that arrives during the build on a list instead of into the running sprint. Most overrun comes not from setbacks but from wishes that arrive along the way.