Most bespoke software projects that reach us don’t start with a grand digital transformation brief. They start with a spreadsheet that someone no longer trusts. A pricing workbook with three versions circulating by email. A rota built from formulas nobody remaining on staff can explain. A stock sheet that two people update at once, and the one who saves last wins.
The spreadsheet is rarely the mistake. Spreadsheets are quick to build, cheap to run, and flexible enough that almost anyone in the business can adapt them without asking a developer. The mistake is not noticing the point at which those same qualities turn against you.
What a spreadsheet is actually good at
It’s worth being precise about this, because the usual advice (“if you’ve outgrown Excel, it’s time for software”) skips the part where spreadsheets are a genuinely good tool for a specific job: one person, or a small group with a shared understanding, working with data that fits on a screen, where the cost of an occasional mistake is low and easily corrected. Forecasting, one-off analysis, a working draft before a process is settled — a spreadsheet does all of that better than a bespoke tool would, because it imposes almost no structure and structure has a cost.
The trouble starts when the spreadsheet stops being a tool one person reasons about and becomes the record the business runs on. At that point, the absence of structure is no longer flexibility. It’s the absence of the things that make shared, operational data trustworthy: a single source of truth, a record of who changed what, and a set of rules the data can’t violate even if someone fat-fingers a cell.
The signs worth taking seriously
None of these on their own means you need bespoke software. Together, or persistently, they’re a reasonable trigger to look properly.
- Formulas have become business logic. If a pricing rule, a commission structure, or an eligibility check only exists as a nested formula in one cell, the business depends on something nobody has documented and few people can safely modify.
- Version control is a filename convention. “Rota_final_v3_USE_THIS.xlsx” is a sign that concurrent editing has become a coordination problem the tool was never built to solve.
- Access control means “don’t touch that tab”. Spreadsheets have no real concept of a user, a role, or a permission. If sensitive data — pay, personal records, supplier terms — sits in the same file as things the whole team edits, you’re relying on discipline rather than a system.
- Reconciliation is a recurring manual task. If someone spends part of every week cross-checking one spreadsheet against another, or against an external system, that’s integration work being done by a person instead of by software, and it will keep costing that much every week indefinitely.
- One person is the system. If the spreadsheet only works because one colleague knows which cells not to touch and quietly fixes it when it breaks, you have a key-person risk sitting inside what looks like a simple file.
- It’s the input to a decision it wasn’t designed to support. A sheet built for a one-off analysis is now feeding a monthly report to the board, or driving a customer-facing process, without anyone having redesigned it for that purpose.
Replacing it doesn’t have to mean a full system
This is where a lot of advice on this topic overstates the jump. “Replace the spreadsheet” doesn’t automatically mean commissioning a full platform. There’s a real range of options, and matching the response to the actual problem matters more than picking the most ambitious one:
- If the core issue is concurrent editing and data integrity, a small database-backed application with a proper form and validation layer — even a single-purpose internal tool with three or four screens — removes most of the risk without the scope of a platform build.
- If the issue is reconciliation between systems, the fix is often integration work — an API connection or a scheduled sync — rather than a new interface for people to learn.
- If the issue is that a process has grown past what one team can coordinate by hand, that’s usually when a purpose-built system — a rota and absence tool, an operations dashboard, a customer record system — earns its cost, because the value isn’t the interface, it’s the rules the software enforces that a spreadsheet can’t.
It’s also worth ruling out off-the-shelf software before assuming a bespoke build. If the process you’re replacing is close to how most businesses in your sector operate, a configured off-the-shelf tool is usually cheaper and faster to get running. Bespoke development earns its cost when the process itself is a source of advantage, or when the available off-the-shelf options force you to bend the process to fit the software rather than the other way round.
The cost comparison people skip
The spreadsheet’s running cost looks like zero because nobody invoices for it. It isn’t zero — it’s just distributed across the people who reconcile it, the time lost when it breaks, and the risk sitting quietly in the file until the day it doesn’t hold. A bespoke tool has an upfront cost that’s visible and a maintenance cost that’s usually smaller than people expect, because a well-scoped internal tool is a fraction of the size of a customer-facing product.
The honest way to compare them is not “spreadsheet is free, software costs money” but to estimate the hours currently spent on manual reconciliation, error correction, and workarounds, and weigh that against a realistic build and running cost for the smallest tool that removes the problem. For most internal tools of this size, that’s a build measured in weeks rather than months — which changes the comparison considerably once it’s actually made.
Questions worth asking before you commission anything
- What specifically breaks today, and how often — is this a recurring cost or an occasional inconvenience?
- Who needs to use the replacement, and does it need role-based access, or is a single shared tool with an audit trail enough?
- Does the data need to reach another system (accounting, HR, a customer portal), or does it currently get copied there by hand?
- Is there an off-the-shelf tool that already does most of this, and what would it cost to bend the process to fit it?
- Who owns the source code, the hosting, and the credentials once it’s built — and can you move it to another supplier if you need to?
A rough decision guide
Keep the spreadsheet if only one or two people use it, mistakes are cheap to spot and fix, and it isn’t feeding a process that other people or systems now depend on. Look at a small bespoke tool when the data is shared, the rules matter more than the layout, and manual reconciliation has become a standing cost rather than an occasional one. Look at off-the-shelf software first when your process resembles the industry norm closely enough that configuring someone else’s tool is genuinely faster than building your own. And treat “one person quietly holds this together” as a risk to fix regardless of which option you choose, because that’s the failure mode that costs the most when it finally shows up.