Building software just got cheap. That's the problem.

Building software just got much cheaper, which means a lot more people are about to build things they shouldn't.

Behavioral science has a name for the mistake they'll make. Uniqueness bias is the belief that your situation is different enough that the usual answer won't apply to you. It has always been an expensive mistake in business. It just got affordable, which is worse, because the upfront price used to be the thing that made people stop and think.

This post is about how to tell whether you're one of the companies that should build anyway. I'll cover why more people are about to build, what the research says happens to the ones who believe they're special, the four questions to ask before anyone writes code, and how two real companies came out on opposite sides of them.

Why more people are about to build

Two things are pushing companies toward building at the same time, and neither one is a good reason on its own. Writing code is getting cheap, and the software people already rent is annoying them more than ever. Bills grow every year, the product doesn't get better, support is worse, and every screen was clearly designed for the average of a thousand other companies.

Being tired of the company you rent from is a reason to rent from someone else, and nothing more. The trouble is that frustration rarely is understood as frustration. It comes out as "nothing out there fits how we work," and that is the belief behind most of the bad projects I've seen.

What believing you're unique does to a budget

The teams that believe their project is unique run the worst overruns, and almost none of them are actually unique. In 2024, a team at Oxford studied 219 IT projects to see how certain behavioral tendencies in management affect project performance and budgets. They asked every team how unique its work was, and about one in five said very unique. Then they went looking for similar projects that had already been done, and they found one for every single team that had called itself unique. The projects that felt the most unique were mostly replacements of old systems, which is the situation a lot of the owners I talk with are in, so if that stings a little, you're in good company. Teams that saw nothing special about their project ran a 1 percent risk of a serious overrun, teams that saw everything special ran a 37 percent risk, and the risk started climbing with the teams in the middle, the ones that only felt a little bit special.

The four questions to ask before you build

The standard advice, buy the product and change how you work to match it, is right most of the time, and these four questions tell you whether you're one of the exceptions.

1. Can the software you already have do this, or can it just not do it the way you're used to? The two feel identical in a meeting. In one study of software rollouts, a manager insisted his salary report was missing fields, and the data was already there in a different report. That isn't a gap, it's a habit, and most of the gaps I hear about start out looking like this one.

2. Would your customers notice if you did this step the way everyone else does? Some of what your company does differently is the reason customers pick you, and most of it is something somebody decided in 2014 that nobody has questioned since. Owning your own code is not an advantage by itself. The way you work can be, and the software is only there to protect it.

3. Have you added up ten years of fixing it, or only the cost of building it? Custom software almost always costs more than an off-the-shelf product and takes more of your time, not just to build but to keep running, and it is much harder to get off your own custom software than to leave a product you rent, because you can cancel a subscription but you can't cancel a system your business has grown around. If the answer is still build, make sure you can say exactly why.

4. Who in your company will own fixing it in ten years, by name? That means the years after the launch, not the launch itself. It can be your own person or a team you pay, but it has to be someone specific who is still going to be around.

Only four yeses make a case for building, and even then only for the one piece those answers point to. Anything less means buy, change how you work, or add a small piece beside what you already have.

What happens when nobody asks

Most build-or-buy arguments never get settled, and the status quo wins by default. The arguments I see are really disagreements about one of these four questions, but nobody says which one, so the two sides talk past each other and the facts never get a chance to settle anything. Sometimes the most senior person in the room ends the debate, but far more often nobody decides at all. The company deadlocks, the decision stalls, and everyone lives with the software they were complaining about for another year.

Two companies, same four questions

One of these companies should have bought and did, the other should have built and did, and the four questions are what told them apart.

A property management company wanted custom dashboards, trend charts, and renewal reminders. The software they already paid for handled 60 to 70 percent of the list in settings nobody had opened, what was left was reports and reminders, and none of it changed who does what. The first question failed on most of the list and the second failed on the rest, so the answer was to keep buying and open the settings.

A construction company wanted its quoting, contracts, and payment requests in one place, and it was different in more than one place, with all of the places on the same path. They build custom pools and the paver work around them, two trades that most software treats as two separate businesses, and here they are one job. The project managers are the salespeople, they run each job from the first phone call to the final payment, and their own sales numbers are how they get paid, so those numbers have to be right and each person can only see and change what is theirs. Which legal disclaimers go on a contract depends on the county, the flood zone, and the kind of job, so a contract has to know where the house is. When a hurricane cancels a signed contract, and that happens most years down there, the cancellation can't wreck the closure rate those same people are paid on. Contracts get signed on a tablet in the customer's backyard, and the office needs to know the moment it happens. Every product made for that industry assumes a salesperson wins the work and hands it to someone else, and the owner had tried one of the big platforms years earlier and dropped it after finding it was built for a business shaped nothing like his. All four answers were yes, but only for that path from first call to final payment, and only because they had someone to keep it up for the long term. So they built that path and bought everything around it, which I'd call a trade rather than a win.

Both of these had issues with their current software, and both made the right call in opposite directions.

Putting it together

Only build custom software when you can prove the critical gap, when that way of working is why customers choose you, when building and keeping it beats renting, and when someone specific will own it for the long term. Anything less than all four, and the better answer is to buy the product, change how you work, or add a small piece beside what you already have. If you're uncertain whether you're the exception, it's time to slow down and get clear on the fundamentals, because this is exactly the point where mistakes happen.

My goal is to put words to a decision that most companies make by default, either because someone senior pushed for it or because nobody decided at all. If it helps, share it with whoever in your company is involved in the decision, that way you're both playing in the same ball field.