When to Replace a Spreadsheet With Custom Software

Spreadsheets fail gradually, then suddenly. The moment of failure is rarely a single crash. It is a slow accumulation of workarounds until one day someone asks a simple question and nobody has a confident answer.

Here are the concrete signs to watch for.

• Version conflicts. The file gets emailed around, renamed to "final_v3_ACTUAL.xlsx", and two people update their own copy on the same morning. By Friday, nobody is sure which row is current. Teams often solve this by designating one person to "own" the file, which quietly makes that person a bottleneck.
• One person who understands it. If the spreadsheet was built by someone who has since moved on, or is about to, that is a risk sitting in your operations. When the formulas break and the person who wrote them is unavailable, the operation stops. This is not hypothetical. It happens in Singapore SMEs regularly, and the cost is a few days of manual scrambling at minimum.
• Manual re-keying between systems. Someone downloads a report from the accounting software, pastes selected columns into the spreadsheet, reformats the dates, and sends it on. That handoff happens daily, it takes time, and every step is a place where a digit gets dropped. When you find yourself building a process around a spreadsheet's limitations rather than your actual work, the spreadsheet is running you.
• No audit trail when something goes wrong. A row gets changed and nobody knows who did it or when. A figure gets queried by a client or an auditor and you cannot show how it was derived. Spreadsheets have no native history unless you have turned on version control in a shared drive, and even then the granularity is usually too coarse to be useful.
• Reporting that takes a day to assemble. If producing a weekly or monthly operations report means someone spends the afternoon pulling figures from three tabs, cleaning data and building a new table, that is not a reporting process. That is a manual job wearing a spreadsheet as a costume. The report is not the work. The work should generate the report.

Before looking at custom software, ask honestly whether the spreadsheet can be fixed rather than replaced. The answer is yes more often than vendors will tell you.

The threshold for custom software is: the process is stable, multiple people are involved, errors have real consequences, and no standard tool handles it without significant compromise. If those conditions are not all met, keep patching.

• If the process is still changing weekly, do not build software around it yet. Custom software encodes assumptions about how your operation works. If those assumptions are wrong, you will either get a system that does not fit, or you will spend money on revisions before the core process has stabilised. A spreadsheet is easy to change. That flexibility is genuinely valuable when a workflow is immature.
• If only two or three people touch it, the coordination problem is small. Version conflicts and audit issues scale with headcount. A three-person team sharing one file, with clear ownership and a simple naming convention, can operate cleanly without investing in a custom system. Better discipline is cheaper and faster than software.
• If the pain is a single broken formula, fix the formula. Bring in someone who knows Excel or Google Sheets well for half a day. A clean rebuild of the same spreadsheet with proper data validation, protected cells and a sensible structure can solve the problem without the overhead of a development project.
• If the data model is simple and the volume is low, off-the-shelf may be enough. There are good tools for inventory, timesheets, field check-ins and basic CRM that cost a few hundred dollars per year. They are worth evaluating before committing to a custom build. Off-the-shelf works when your process is standard. When it is not, you spend more time configuring around limitations than using the product.

We built FieldCheck for Chinatown Foods Pte Ltd, a Singapore frozen food company that needed to manage field staff visiting outlets across the city.

The old process was WhatsApp. An agent reaching an outlet would send a selfie to the group. It worked in the sense that something arrived, but a selfie proves a photo was taken, not where it was taken. No location, so no way for a manager to confirm anyone was on site. And because the whole record was photos in a chat thread, there was nothing structured left to analyse: no clean answer to which outlets were covered, how often, or where the gaps were.

What replaced it works like this. When a staff member checks in at an outlet, the app captures their GPS coordinates and validates them against the outlet's registered location using Haversine distance. They have three attempts to check in from within the geofence. If the outlet is not in the system (a new or unlisted site), they log it for admin review and the location is geocoded and promoted to the active list once confirmed. A mandatory selfie is captured at check-in. Admins see all of this in a dashboard where they manage staff and outlets. At 10pm Singapore time each day, the system generates a CSV report automatically. Photos are cleaned up after seven days. Reports are kept indefinitely.

The result is a record that cannot be faked, requires no manual collation, and is available to any authorised admin the moment it is generated. The field team's work becomes legible to the office without anyone spending time on it.

The fixed quote for the build was S$4,500.

“This completely changed the way we operate, and gave us the ability to monitor performance.”

The part most operations managers dread is the sales process: multiple meetings, a requirements document that takes weeks to produce, a quote that arrives with seventeen caveats and a range so wide it is useless.

That is not how this works.

One conversation is enough to scope a build like FieldCheck. The call covers what the process currently looks like, where it breaks down, who uses it and on what devices, and what a good outcome looks like. No NDA is required before that conversation. There is nothing to sign.

At the end of the call there is a fixed quote. Not a range, not "it depends on final requirements". A number, with scope attached. If the scope changes later, that is discussed before any work changes. The quote is the deliverable of the scoping call, not a step in a longer sales process.

If the quote does not make sense for the business, the conversation ends there. No obligation.

From a fixed quote, the typical build takes four to ten weeks. A live link exists from week one. Weekly demos show the actual product, not mockups. At the end, you receive full documentation, all credentials, and all data. The code is yours. There are no exit fees and no lock-in. Twelve months of defect support is included, with a next-business-day response commitment.

If your spreadsheet has been causing quiet problems for a while and you want to know whether there is a sensible option, a scoping call is the lowest-risk way to find out. It costs nothing, and you will leave with a clear answer either way.