Most business software starts life as a spreadsheet, and that is not a bad thing. A spreadsheet is the fastest way to find out what a process actually needs. Someone builds a few columns, adds a formula, and the business runs on it for years.
The trouble starts quietly. The file gets copied. One person knows which tab to paste into. A formula breaks when someone sorts the wrong range, and nobody notices until the totals look odd. By then the file is carrying far more weight than anyone meant it to, and the business is exposed every time it gets opened.
Signs it has outgrown the file
None of these on its own means you need custom software. Three or four together usually do.
- Someone copies data in by hand from another system. If a report gets exported from your booking, scheduling or point-of-sale software every week and pasted into a sheet, that step will eventually go wrong.
- Only one person understands it, and when that person is away the process stops or gets done badly.
- The rules live in people's heads. "Travel days pay a different rate" and "refunds come off the next period" are business rules, and if they aren't written into the system they get applied unevenly.
- Two people work on copies, then someone merges them by eye.
- Nobody can quickly answer "why is this number what it is?" The total is there, but tracing it back to the inputs takes an afternoon.
- Mistakes cost real money. Payroll, pricing, invoices and commissions are where small errors add up fastest.
- Staff in the field need it on a phone, and a forty-column sheet on a small screen doesn't work.
Map the process before you touch the code
Before the web, I designed power plants. The first real document on any plant job was the process drawing: every pipe, valve, pump and instrument, and what flows between them. Nobody ordered steel until that drawing made sense to everyone who had to build and run the plant. The same habit works for software.
We start by drawing the process as it really runs today, which is rarely how it was supposed to run. For each step we write down:
- Where the data comes from: another system, a person, an email.
- Who touches it, and what they change.
- Which rules get applied, in plain English.
- Where it goes next, and who relies on it.
- What happens when it goes wrong, and how anyone finds out.
This usually takes a couple of conversations and a shared document. It almost always turns up something nobody had written down. Usually that's a manual correction someone makes every month, or a rule that only applies at one location. Once in a while it's an entire side report that exists because nobody trusts the main one.
The first version should be small
The temptation is to rebuild the whole process at once. I'd resist it. Look at the map and find the step that breaks most often, or costs the most when it does, and put the first version there.
A good example is a payroll tool we built for a med-spa. Their appointments, services and sales already lived in a scheduling and point-of-sale platform (Zenoti), which has an API: a documented way for other software to request data. Payroll for that kind of business has a lot of rules that are easy to say out loud and hard to apply by hand:
- different pay tiers for mobile visits, with travel and rush bonuses
- tips split between the nurses who worked a visit
- staff treatments kept separate from customer treatments
- refunds and consults handled differently from paid services
- new nurses picked up automatically when they first appear in the data
The app pulls the data from the API every night, applies those rules in code, and shows the result for review. The most important design decision was what happens when a person disagrees with the result. A manager can edit a figure, and that edit is locked so the next nightly import can't overwrite it. That one rule respects the fact that people know things the data doesn't, without letting manual fixes quietly disappear.
We didn't try to replace the scheduling platform, the accounting system or anything else that was working. The app sits between them and does the one job that was fragile.
Later additions followed the same pattern. A one-click "update database" button applies changes when the app is updated. A one-click download gives the raw data for any day, so any number can be checked against its source. Deploys run automatically from a git repository to the servers, so an update never depends on someone copying files by hand.
What the spreadsheet is really costing
The case for an app comes down to cost, and most of that cost is hidden. Before recommending a build, we try to measure it.
- Time per cycle. How many hours each week or pay period go into exporting, pasting, checking and fixing? Ask the person who does it, then watch them do it once. The second number is usually higher.
- Error rate. How often has a total been wrong in the last year? What did each mistake cost to find and fix, including the awkward conversation with the person who was underpaid?
- Key-person risk. What happens if the one person who understands the file leaves, or is simply out sick on the wrong week?
- Delay. How long after the period ends does the business know its numbers? Decisions made on last month's data are slower and worse.
Put a rough number next to each one. If the total is a few hours a month and errors are rare, keep the spreadsheet and tidy it up. If it is a day a week and there have been payroll mistakes, an app usually pays for itself quickly.
Rules for the replacement
When we do build, a few rules apply to every project.
- The source of truth stays where it already is. If the scheduling system owns the schedule, the app reads from it and never becomes a second copy that slowly drifts.
- The rules get written down twice, once in code and once in plain English, so the client can read a list of the pay rules and confirm each one.
- Every total leads back to the rows that made it.
- People can correct the numbers safely. Manual edits are allowed, recorded and protected from being overwritten.
- It works on a phone. Staff who need to check something shouldn't need a laptop.
- We back up before every change, because the data in a tool like this is often the only copy of who was paid what, and why.
Not every spreadsheet should become an app. Many should simply be cleaned up, with the input cells locked and the formulas documented. The question I ask is whether the process now matters too much, and carries too many rules, to keep living in a file that one person understands.
If a spreadsheet is quietly running part of your business, tell us what it does and where its numbers come from, and we'll give you an honest opinion on whether it's worth building. The contact page is the quickest way to reach us.