The spreadsheet has become important enough that everyone wants to replace it. That does not yet tell us whether the business needs a new application.
It might need a better spreadsheet. It might need an existing product with a small integration. It might have a workflow distinctive enough to justify custom software. I would make that choice by examining the work and its failure modes before comparing interfaces.
The first question I want answered is concrete: what happens when the current process goes wrong, and what does recovering from that mistake require?
Write down one complete transaction
Consider a hypothetical business handling supplier invoices in a shared workbook. An invoice arrives, someone checks it against the purchase, a manager approves it, and accounting schedules payment.
The ordinary path is easy to demonstrate. The revealing cases are a partial delivery, an invoice that arrives twice, a changed bank account, an absent approver, and a credit note received after payment. Each one exposes a rule or responsibility that a new tool must preserve.
Trace one invoice from arrival to the final accounting entry. At every handoff, identify the input, decision, owner, and evidence. If nobody can explain who resolves a price discrepancy today, a software purchase will not settle the question.
The resulting workflow description is useful whichever option wins. It can become a spreadsheet procedure, a product evaluation script, or the acceptance criteria for a custom build.
Separate distinctive rules from ordinary plumbing
Joel Spolsky’s argument for sometimes building core software yourself (opens in a new tab) is a useful counterweight to reflexively buying everything. But “important to the business” is a broader category than “needs to be invented by this business.”
For the invoice workflow, receiving files, controlling access, storing approvals, and exporting accounting data may be well served by an established product. A genuinely unusual allocation rule may deserve a small custom service. Those choices can coexist.
I would be skeptical of a custom application whose main purpose is to recreate standard approval screens. I would also be skeptical of a purchased product that requires the business to maintain an elaborate workaround for its most frequent decision. The cost can move from code into configuration without disappearing.
Brandon Byars makes a related distinction in You Can’t Buy Integration (opens in a new tab): buying an integration tool still leaves integration work to be done. A connector can move fields successfully while the two systems disagree about what those fields mean.
Put the alternatives on the same cost basis
Suppose someone proposes a $12,000 custom application to eliminate four hours of weekly work. At a hypothetical fully loaded labor cost of $60 per hour, the current work costs $12,480 over 52 weeks.
That does not imply the application pays for itself in a year. Some review will remain. Hosting, maintenance, access management, migration, and support will have costs. Recovered hours may create capacity without reducing payroll.
The following figures are illustrative assumptions, not market prices or a forecast for a particular business:
| Annual operating cost | Improved workbook | Purchased tool | Custom application |
|---|---|---|---|
| Remaining work | 3 hours/week | 1 hour/week | 0.5 hours/week |
| Labor at $60/hour, 52 weeks | $9,360 | $3,120 | $1,560 |
| Subscription or hosting | $0 incremental | $2,400 | $600 |
| Ongoing maintenance/support | $600 | $600 | $3,000 |
| Total recurring cost | $9,960 | $6,120 | $5,160 |
Now add hypothetical one-time costs of $1,000, $3,000, and $12,000 respectively. Over two years, the totals are $20,920 for the workbook, $15,240 for the purchased tool, and $22,320 for the custom application. The original process would cost $24,960 in labor over the same period.
Under these assumptions, the purchased tool has the lowest two-year total, while the custom application has the lowest recurring cost. Change the maintenance burden, useful life, or remaining review time and the ordering can change. The calculation exposes those dependencies; it does not settle the decision by itself.
Test the awkward cases before committing
Give each option the same small evaluation set: an ordinary invoice, a duplicate, a partial delivery, a rejected approval, and a correction after posting. Use sanitized or synthetic records where appropriate.
Ask the person doing the work to complete each case. Watch where information gets retyped, where the next owner is unclear, and where the system requires an administrator to recover. Then export the records. A tool that is easy to enter data into but difficult to leave has an additional cost.
For a spreadsheet, inspect permissions, protected formulas, input validation, version recovery, and whether one person has become the only reliable interpreter. For a purchased product, inspect the relevant plan’s limits and the actual integration. For custom software, name who will operate and maintain it after the initial builder is unavailable.
A useful pilot has an exit condition: which cases must work, what evidence is required, and what result would cause the business to stop. Otherwise a modest experiment can become a permanent second system.
Choose the smallest change that survives the real work
A spreadsheet can be a reasonable tool for a small, stable process with clear ownership. It becomes a weaker fit when concurrent changes, permissions, auditability, or complicated handoffs overwhelm its controls. A custom application can solve those problems, but it also creates an operating responsibility.
Choose the option whose total cost and operational demands fit the business. Revisit it when the underlying conditions change. More transactions, a new approval requirement, or repeated recovery work are better reasons to reconsider than the arrival of another attractive dashboard.