When a business actually needs a custom web application.

An off-the-shelf product arrives with years of accumulated edge cases already handled, a support function, a security posture somebody else maintains, and a roadmap you did not have to fund. Choosing to build instead means taking all of that on — not once, but continuously, for as long as the business depends on it.

That is the real cost, and it is routinely underestimated because the initial build is the visible part. The invisible part is the next five years: the browser that changes behaviour, the integration that deprecates its API, the person who understood it leaving, the new requirement that does not fit the original model.

So the default should be buy, and the burden of proof should sit with building. What follows is what actually meets that burden.

This is the question that separates the two cases, and it is more useful than any feature comparison.

If your process is essentially the same as everyone else's in your industry — invoicing, scheduling, basic CRM, standard accounting — then a product built for thousands of similar businesses will beat anything you build, because it has absorbed thousands of variations of your problem. Bending your process to fit it is usually the cheaper trade.

But if the way you do a particular thing is a reason customers choose you, then forcing it into a generic tool has a specific cost: you are trading away the thing that differentiates you in order to save on software. That trade is sometimes worth it. Often it is not, and the business only notices later, when the process has quietly flattened into whatever the tool allowed.

A shortcut version: if the answer to why do you do it that way is because the software does it that way, something has already been lost.

None of these is sufficient on its own. Together, they are usually the point at which the arithmetic changes.

• THE SPREADSHEET IS THE SYSTEM

  A critical process runs on a spreadsheet that several people edit, that has grown rules only one person understands, and that would cause real damage if it were lost or corrupted. That is already a custom application — just one with no validation, no access control and no audit trail.

• THE TOOL IS BEING FOUGHT

  The team has developed elaborate workarounds: duplicate records to represent a state the tool lacks, a naming convention that encodes information the schema will not hold, a parallel tracker because the real one cannot express the process.

• THE INTEGRATION IS THE PRODUCT

  The value is not in any single tool but in how several of them combine, and no vendor owns that combination. The connective layer is where the business logic actually lives.

• LICENCE COST SCALES WRONG

  Per-seat pricing grows with headcount while the value delivered grows with something else entirely — transactions, clients, locations. The cost curve and the value curve have separated.

The framing of build versus buy hides the option that most often turns out to be right: buy the commodity parts, build the part that is genuinely yours, and connect them deliberately.

Keep the accounting package. Keep the CRM. Build the workflow layer that sits between them and encodes how your business actually operates — the part no vendor sells because it only exists here. This is usually a much smaller piece of software than a full platform, and it is the piece that carries the differentiating logic.

It is also the piece most likely to survive, because it is scoped to something real rather than to a fantasy of replacing everything.

Before any build begins, a small number of questions decide whether the result becomes an asset or a liability. Who owns the code and the infrastructure accounts. Who maintains it once the initial work is finished. What happens if the person who built it becomes unavailable. What the data looks like if the business ever wants to move on from it.

Security also belongs in the decision before the first feature is scoped. NIST's Secure Software Development Framework describes practices that can be integrated into a development lifecycle rather than bolted on after release. CISA's procurement guidance makes the complementary point for buyers: ask how a manufacturer takes ownership of security outcomes, uses secure defaults and provides evidence. A custom application does not inherit those practices merely because it is custom; the buyer and builder must make them explicit.

These are unglamorous questions, and they are the difference between commissioning a system and acquiring a dependency. A business that cannot answer them is not ready to build yet — not because the software is beyond it, but because the ownership is undefined, and undefined ownership is how custom software becomes the thing nobody wants to touch.

1. Buy is the correct default; the burden of proof belongs with building.
2. The deciding question is whether the process itself is part of how the business competes.
3. Warning signals: a spreadsheet running a critical process, elaborate workarounds, value living in the integration, licence cost scaling against value.
4. The best answer is usually hybrid — buy the commodity, build the differentiating workflow layer, connect deliberately.
5. Ownership, maintenance and exit questions decide whether custom software becomes an asset or a liability.