When custom software beats the spreadsheet — and when it does not

A spreadsheet that runs a business process is often criticised unfairly. It was built by the person who understands the process, it changes in minutes when the process changes, and it cost nothing. Those are genuine advantages that custom software struggles to match. Any honest case for replacing a spreadsheet has to acknowledge them.

What spreadsheets lack is not capability but control. Specifically: validation, concurrency, audit trail, permissions and backup. Each absence has a cost that stays invisible until it does not.

The five failure modes

Every spreadsheet-run process we have replaced failed in at least one of these ways:

• Validation — a typed value that should have been impossible. A quantity of 1,000 instead of 100, a date in the wrong year, a formula overwritten by a paste.
• Concurrency — two people editing simultaneously, one set of changes lost silently.
• Audit trail — a number that changed, and no record of who changed it, when, or why.
• Permissions — everyone who can read can also modify, including data they should not see.
• Continuity — one person understands the file, and the business is exposed when they leave or take leave.

The last is the most common trigger for engagement. A business discovers that a critical process depends on one person and one file, and that neither is documented. The risk is not theoretical — it is the reason we are frequently called in during someone's notice period.

The arithmetic of replacement

The decision should be a comparison of two costs, not an aesthetic preference. On the cost of keeping the spreadsheet:

• Hours per week spent on manual data entry, reconciliation and chasing.
• Error frequency multiplied by the cost of each error, including customer impact.
• Time lost when the file breaks or someone overwrites a formula.
• The cost of the key-person risk, which is real even if hard to quantify.
• Growth constraint: if every new client adds manual work, that is a ceiling with a price.

Against that, the cost of building: an initial engagement (our smallest internal tool builds start around $4,800 and deliver in three to four weeks), plus ongoing maintenance, plus the change in agility — because software changes in days where a spreadsheet changed in minutes.

That last point deserves honesty. Replacing a spreadsheet with software trades flexibility for control. If the process genuinely changes weekly, software may be the wrong answer and a better-controlled spreadsheet — with validation, version history and restricted editing — may be the right one.

Where the threshold usually sits

In practice, the case for building becomes clear when two or more of these are true:

• The process consumes more than five hours per week of manual work.
• An error in it has customer-visible or financial consequences.
• More than three people need to use it concurrently.
• You need an audit trail for compliance, dispute resolution or investor scrutiny.
• Volume growth means the process needs more headcount to scale.

Below that threshold, improving the spreadsheet is often the better engineering decision. We have advised clients to do exactly that, and declined the build.

Do not rebuild the spreadsheet

The most common mistake in replacement projects is treating the spreadsheet as the specification. The spreadsheet contains the process plus a decade of workarounds for the spreadsheet's own limitations. Rebuilding it faithfully produces software that inherits every one of those workarounds.

The right approach is to map the process the spreadsheet serves, then design for that process directly. In a recent engagement the client's file had four tabs devoted to reconciling data between two systems. The replacement did not need them at all — an integration removed the reason they existed. Had we rebuilt the tabs, we would have automated a problem instead of eliminating it.

Start smaller than you think

Businesses frequently scope a replacement as a platform covering every adjacent process. That produces a six-month project with high failure risk. The better path is one tool replacing one spreadsheet, delivered in three to four weeks, with the next one funded by the value the first produced.

This also surfaces the requirements you did not know you had. A team using working software for a month generates better requirements than the same team in a workshop, because software makes the gaps concrete.

Three questions before you commit

• What specifically breaks today, how often, and what does each occurrence cost? If you cannot answer, measure before building.
• What does this process look like if you design it from scratch rather than replicating the current file?
• What is the smallest version that removes the most expensive failure mode?