Build, Buy or Configure — When Custom Software Pays Off

It is an unusual way to begin a document: the best advice a software company can sometimes give is not to have any software built. That sounds like it runs against our own interest, and that is exactly what makes it credible. Because the most expensive projects are not the ones that fail but the ones that should never have started — custom software built for a problem that an off-the-shelf product would have solved better and more cheaply.

This document addresses the question that comes before all technical questions: build, buy or configure. It stays honest even when the answer is "buy," because a recommendation is only worth as much as the willingness to advise against your own business when the matter demands it. It names no product and no figure; it describes the criterion by which the decision can be made honestly.

1. The real question

The question is not "should we build software?" but "does this problem justify software of our own — or does someone else solve it better?" Almost every business problem has been solved before, often by many, often in the form of a finished product. The probability that your own problem in particular is so special that it demands software of its own is lower than it feels from the inside.

That is why the starting point is not design but scrutiny: does this already exist? And if so, why would what we build be better than what is available? Whoever skips this question is not consciously deciding to build but simply missing the chance not to. Sometimes the first engineering achievement is not building.

Trade-off. Taking the question seriously means setting aside the appeal of building your own and tolerating the possibility that the right answer means less work for us.

Cost. Honest scrutiny costs time before the project and the willingness to scale down or cancel an initiative before it has started.

When we decide differently. Where obviously no finished product touches the problem — a process that exists only in this company — lengthy scrutiny is unnecessary, and you move on to building quickly.

Why do so many people skip this question? Because building flatters our self-perception. "Nobody understands our business the way we do" feels right, and the desire for full control is understandable. Both, however, easily lead to considering your own problem more special than it is — and to expensively building the ordinary yourself in the belief that it is unique. Sober scrutiny is therefore also a check on your own organizational blind spots: is this process really what sets us apart — or just our habitual way of doing something common?

2. What build, buy and configure mean

The three paths are not sharp categories but points on a spectrum. At one end is Buy: a finished product, used as it is. In the middle is Configure: a platform you adapt to your own needs without building it — you work within its limits. At the other end is Build: your own software, tailored precisely to your own problem. Between these points lie hybrid forms; most real systems are a combination.

Diagram: From left to right, control over the solution grows — and with it effort and responsibility. No position is superior; each fits a different problem.

The point of this classification is to see the decision as a choice on a spectrum, not as a yes/no to building. Often the right answer is a mix: buy what is common, build what is special. Whoever knows the spectrum does not look for the one solution but for the right distribution.

Trade-off. Moving right on the spectrum buys fit and control at the cost of effort and permanent responsibility — moving left saves both, at the price of adapting to someone else's solution.

Cost. Each position has its own cost structure that you need to know before choosing (see chapter 6); the wrong choice doesn't show immediately but over years.

When we decide differently. Where a single product covers the entire problem cleanly, mixing doesn't pay off; you buy it and spare yourself the complexity of multiple building blocks.

3. When buy is right

Buying is the right choice when the problem is common and solved — when many companies need the same thing and a market exists for it. Accounting, mailboxes, calendars, the usual building blocks of operations: here the probability is high that a finished product is more mature, cheaper and more reliable than anything you could build yourself in a reasonable time. The vendor spreads its development costs across many customers; you would bear them alone.

The decisive point is that a purchased product for a common problem is not only cheaper to acquire but also takes the permanent burden of maintenance off your hands. You buy not only the functionality but also its future — the bug fixes, the further development, the adaptation to new requirements that will come anyway. For everything that does not distinguish your company from others, that is the smarter path.

On top of that comes a price that never appears on an invoice: the attention you lose. Every hour a team puts into rebuilding the ordinary is missing where the company truly differs. Engineering capacity is the scarcest resource any initiative has, and it cannot be split — what flows into the solvable that others have already solved does not flow into what is your own and only you can solve. The strongest reason to buy the common is therefore not the lower price but that you save your own strength for what matters.

Trade-off. Buying buys maturity and low effort at the cost of fit — you conform to the product's assumptions instead of defining them.

Cost. A purchased product brings a dependency with it: ongoing fees, lock-in to a vendor, the limits of its conception of the problem (see chapter 6).

When we decide differently. As soon as the common product only roughly matches your own problem and the gap lies at the core of the business, buying is no longer enough — that is where the territory in which building pays off begins.

4. When configure is right

Configuring is the right choice when a platform comes close enough to your own needs that adapting it is cheaper than building — and when you are willing to live with its limits. Many platforms are made precisely for this: a solid framework that you adapt to your own processes without development of your own. You get a large part of the way for free and only shape the rest.

The art of configuring lies in an honest view of the limits. A platform carries the assumptions of its builders; you can bend it, but not arbitrarily. As long as your own processes stay within those assumptions, configuring is a good trade. As soon as you start forcing the platform against its nature — customization upon customization to achieve something it was not meant for — the math tips, and in the end you pay more than for building your own and get less.

Trade-off. Configuring buys a large head start at the cost of being bound to the platform's limits — you inherit its strengths and its assumptions at the same time.

Cost. Every customization couples you to the platform and has to be carried along as it evolves; too many customizations turn the head start into a burden.

When we decide differently. Where you begin systematically bending the platform against its nature, configuring has lost its advantage — then honestly admitting that you are actually building is cheaper than continuing to bend.

5. When build pays off

Building pays off in a narrow but real area: where the software itself is the difference. When a process sets your company apart from others, when no product represents it because only this company has it in this form, or when the limits of what can be bought cost more at the core than building would — then custom software is the right answer. You build what defines you and what has to last a long time.

The yardstick is not whether you could build — you can build almost anything — but whether what you build creates value that what you buy cannot. That value almost always lies in one of two places: in differentiation, because the software provides a capability competitors cannot get off the shelf; or in fit, because an essential process of your own cannot be squeezed into someone else's corset without suffering expensively. Where neither of these is touched, building is an expensive way to get what you could have bought.

Trade-off. Building buys full fit and control at the cost of the highest effort and permanent responsibility for maintenance and further development.

Cost. Your own software does not end with its completion; it has to be operated, maintained and adapted over its entire lifespan — and you bear these costs alone.

When we decide differently. As soon as a finished product matches the problem well enough and the difference does not lie at the core of the business, building is the wrong choice — then you buy and direct your own strength toward what truly differentiates.

Moreover, the decision does not have to be made forever. Often the smartest path is to start by buying and to build only once it becomes clear that a finished product really limits your own advantage. You buy while you don't yet know the problem precisely, and replace what you bought with your own once the differentiation is visible and proven — the same stance as everywhere: don't commit early, but make the expensive, hard-to-reverse choice when you know the most. Building is rarely urgent; it can almost always be done later once the reason for it is established.

6. The hidden costs of each option

Each of the three paths has costs that lie in the shadows at the time of the decision and only become visible over the years. Knowing them matters more than the purchase price, because over the lifespan they decide the math.

The most common mistake is to compare only the visible costs — the purchase price against the development costs — and to overlook the hidden ones. Buying looks cheap until vendor lock-in becomes expensive; building looks expensive until you realize it was the only thing that truly supported your own process.

With your own software, the hidden cost category is the largest: building is only the tip; maintenance over the lifespan is the hull beneath it. Your own software has to be operated, updated, adapted to new requirements and understood over years — including by people who didn't build it. Whoever only calculates development and forgets maintenance systematically underestimates the true costs of building. The same commitment that makes custom software so valuable — it belongs entirely to you — also makes it permanently expensive: there is no vendor sharing the burden of its future. The honest calculation does not set price against price, but total cost over the lifespan against the value the solution creates at the core of the business.

Trade-off. Taking hidden costs seriously means doing a slower, less comfortable calculation instead of being guided by the low purchase price.

Cost. A full lifespan calculation requires assumptions about the future that you cannot know for certain — you calculate with uncertainty, but more honestly than with the mere price.

When we decide differently. For a small, short-lived purchase, comparing prices is enough; the full lifespan calculation only pays off for decisions that bind the company for years.

7. The criterion: differentiation and lifespan

In the end, all three paths converge on a single criterion: build what sets you apart and has to last a long time; buy or configure what is common and interchangeable. The core of the business — what you do better than others and what the company depends on — deserves its own software, because you don't want to place it in someone else's hands and someone else's assumptions. Everything else, the necessary but non-differentiating, you buy.

Diagram: Two questions decide — does the problem set us apart, and is there a product that fits? Only in the top left, the differentiating area without a ready-made answer, does building necessarily pay off.

Lifespan sharpens the criterion. Something that has to last a long time you are reluctant to tie to a vendor whose future you don't know; something short-lived you can buy without hesitation. Differentiation and lifespan together yield the honest answer: the long-lived core of the business is built, the short-lived or interchangeable periphery is bought — and most things lie in between and are mixed.

Trade-off. Deciding by this criterion requires honestly naming what truly sets you apart — and that is often less than you would like to believe.

Cost. The criterion forces a nuanced answer rather than a convenient rule; you have to judge each building block anew instead of saying "build" or "buy" once and for all.

When we decide differently. Where differentiation and lifespan are both low, you skip the fine-grained weighing and buy; the full criterion applies to the building blocks that touch the core or the longevity of the business.

8. Common mistakes

The recurring patterns on which the decision fails — almost all of them are variants of skipping the criterion:

• Thinking about building right away without checking whether the problem has long been solved and can be bought.
• Buying what differentiates you and placing it in someone else's assumptions — thereby giving up your own advantage.
• Building what is interchangeable — expensively producing yourself what you could have bought more mature and cheaper.
• Comparing only purchase prices and overlooking the hidden costs over the lifespan.
• Bending a platform against its nature for so long that configuring becomes more expensive than building would have been.
• Overestimating your own differentiation and mistaking what is actually common for something unusual.
• Deciding as if there were only build or buy, and overlooking the mix that is usually the right one.
• Tying a long-lived core system to a vendor whose future you don't know.

9. Decision checklist

Before every build, buy or configure decision, clarify in order:

• Already solved? Is there a finished product for this problem — and if so, why would your own be better?
• Differentiating? Does this building block set us apart from others — or is it necessary but ordinary?
• Lifespan? Does it have to last a long time, or is it short-lived and replaceable without hesitation?
• Fit? Does a product or platform match the problem well enough — or only roughly, and does the gap lie at the core?
• Hidden costs considered? Have I compared total costs over the lifespan, not just purchase prices?
• Mix examined? Can the common parts be bought and only the special parts built?
• Platform limits? When configuring: am I staying within the platform's assumptions — or bending it against its nature?
• Lock-in acceptable? When buying: is dependence on the vendor justifiable for this building block?

If you can answer these questions, you have decided whether the problem deserves software of its own — and not merely that you could build some.

FAQ

Does a software company really sometimes say "don't build"? A responsible one does. The most expensive software is the software that should never have been built — something custom for a problem a product would have solved better. Whoever only builds serves their short-term business; whoever also advises against it when the matter demands serves the client and earns the trust that is worth more in the long run.

Isn't buying always cheaper than building? Often at the time of purchase, not always over the lifespan. A purchased product brings fees, vendor lock-in and the limits of someone else's assumptions; if it doesn't fit at the core, the sum of these costs can exceed building. The honest calculation sets total cost over time against the value created, not price against price.

How do I recognize what I should build? By differentiation. Build what sets you apart from others and what has to last a long time — the core the business depends on. Buy or configure what is common and interchangeable. The most common mistake is to buy your own advantage and build the ordinary — exactly the wrong way around.

What about configuring as a middle path? Configuring is strong when a platform is close enough to the need and you can live with its limits. It tips as soon as you systematically bend it against its nature — then in the end you pay more than for building your own and get less. Honestly admitting that you are actually building is then the cheaper choice.

Do I have to decide on one path? Rarely. Most systems are a mix: the common parts bought, the special parts built, a platform configured for the framework. The question is not "which path" but "which distribution" — which building block deserves which path.

How does this relate to longevity? Closely. What has to last a long time you are reluctant to place in someone else's hands whose future you don't know; what is short-lived you buy without hesitation. Lifespan and differentiation together yield the answer — the long-lived core is built, the interchangeable periphery bought.

Further reading

• Software that still runs in ten years — why lifespan also determines the build-buy decision.
• Mature technology over novelty — the same sobriety, applied to choosing technology rather than procurement.
• Why software projects really fail — why the most expensive project is often the one that should never have started.
• Reversibility over prediction — choosing building blocks so that a path remains reversible later.

It is grounded in the Batunet Engineering Method: first check whether anything needs to be built; build what differentiates, buy what is ordinary, deliberately mix the rest.

Closing engineering principle

The rule that holds everything together is short: build your core, buy your periphery. What differentiates you, has to last a long time and the business depends on, you don't place in someone else's hands — there you build, because you don't want it taken from you. The ordinary, which many need and which a market provides more maturely and cheaply, you buy — building there would be expensive vanity. Most mistakes in this question are confusions of these two sides: buying the core and thereby giving away the advantage, or building the periphery and thereby tying money and attention to the wrong thing. Whoever separates the two cleanly directs their scarcest resource — their own engineering capacity — toward what truly counts.

The first question is never how to build something, but whether. An engineer's most mature answer is sometimes not to do it — and to say why.