Not every workflow needs custom software. Three conditions hold where Excel beats a database, and missing the moment to migrate is also a real cost. The honest version of the question.
By Mohammad Jamnagarwala · Simply Five Studio
A founder running a consulting practice asked us, in our first conversation, what software we would recommend to replace the spreadsheet his team used to track engagements. We asked him to describe the spreadsheet. He described twelve columns. He described three users. He described a workflow that had not changed in two years and was unlikely to change in the next year. We told him to keep the spreadsheet. He looked surprised. We were not in the room to sell him software. We were in the room to give him an honest answer.
The honest answer is that not every workflow needs custom software. Excel beats a database in a specific set of conditions, and a firm that builds software for workflows that should have stayed in Excel ends up with the wrong tool for the work. The opposite mistake is also real: keeping Excel past the point where the volume, the user count, or the workflow stability has moved makes the firm pay the hidden cost every day until the move happens.
This essay is the threshold. Three conditions under which Excel is the right answer, and the signals that say the window has closed.
The first condition is volume. Excel handles fifty entries per day gracefully. At a hundred entries per day, the file is still workable but slower to open, and the sort-and-filter discipline required to keep it usable starts to show. At two hundred entries per day, the file is fighting back. Multiple users overwriting each other's edits, copy-paste errors that compound, and the search problem of finding a specific record three months later become material.
The threshold is not exact. It depends on the columns, the formulas, and the file structure. The rough heuristic that holds is fifty entries per day. Below it, Excel is the right tool. Above it, Excel starts costing the team more time than a focused database would.
The volume signal to watch is not the entry rate alone. It is the read rate. A spreadsheet with twenty entries per day but five people reading it forty times a day is functionally a high-volume file. The read traffic is the load, and the read traffic is what produces the contention and the version drift.
The second condition is the user count. Excel handles one user well. It handles two users in shared mode, awkwardly, with merge conflicts that the team learns to navigate. It handles three users at the edge of what is workable. Past three users, the coordination cost exceeds the cost of moving to a system with proper concurrency.
The user count matters more than founders typically realise. A spreadsheet with two users updating it has a single source of truth that survives because the two users are in regular contact. A spreadsheet with five users updating it has effectively five working copies that diverge silently. The reconciliation work happens on Friday afternoon and is invisible to the founder until a customer escalates an error that was caused by it.
When the third user joins the spreadsheet, the question to ask is not whether the spreadsheet still works. It does. The question is whether the team's time on coordination has become a tax that a database would remove.
For ISM Business Associates, the move from Excel to the custom calculator was driven exactly by this. The original Excel sheet had grown to support a team of four salespeople working on customer quotes at the same time. The collisions in the file were daily. The corrections were weekly. The calculator absorbed the workflow because the workflow had outgrown the file, not because the file was wrong on its own terms.
The third condition is the most subtle and the most often missed. Excel is the right tool when the workflow is still being figured out. The team is iterating on what to track, how to track it, what the columns mean, what the categories should be. Excel allows this iteration at zero cost. A database does not.
A database imposes structure. Adding a field is a code change. Renaming a category requires data migration. Splitting a column into two requires thinking through every dependent query. Excel allows the team to add a column on Tuesday, remove it on Thursday, and rename it on Friday, all without anyone asking for a release note. This flexibility is a feature when the workflow is in discovery mode, and a bug when the workflow has stabilised.
The signal that the workflow is in flux is the rate of structural change in the spreadsheet. If the columns are different from last quarter, the workflow is still being figured out. If the columns have been the same for a year, the workflow has stabilised and the structure is now load-bearing. A load-bearing structure in a spreadsheet is a quiet liability. Two of the columns being overwritten by mistake takes down a workflow the firm has come to depend on.
For Taheri Foundation's task assignment portal, the move from spreadsheet to portal happened after the workflow had been stable for a year. The columns had not changed. The categories were settled. The team had stopped iterating on the structure. That was the signal. The portal could be built against a known specification because the specification existed in the spreadsheet.
A firm that should have moved off Excel six months ago has a recognisable set of symptoms. The spreadsheet has lookup tables on hidden sheets. The macros run during open. The file size is in the tens of megabytes. There is a "master" copy and several "working" copies, and the team has a ritual for merging them. Someone has been assigned, informally, as the spreadsheet custodian. The founder has stopped opening it because it takes too long.
When two or more of these signals are present, the migration window closed already. The firm is paying the migration cost daily in small amounts, instead of paying it once in a bounded amount. The right move is to migrate now, before the spreadsheet collects another six months of accreted complexity that has to be untangled during the move.
The longer treatment of the SaaS-versus-custom math, which is the next question after the spreadsheet-versus-software question, is in this essay. The diagnostic for whether a firm has outgrown its accounting tool is adjacent and worth a separate read at the Tally diagnostic.
Before building software for any workflow, the three-question diagnostic. How many entries per day. How many concurrent users. Has the structure of the workflow been stable for at least six months. If volume is below fifty, users below three, and the structure is still moving, the answer is the spreadsheet. The software conversation is premature.
If any one of the three has crossed (volume past fifty, users past three, structure stable for a year), the spreadsheet is starting to cost more than it returns. If two of the three have crossed, the conversation is already overdue.
The work we do under the internal systems practice begins, in many engagements, with this question. The diagnostic is the same diagnostic the founder should run before asking us. Sometimes the answer we give is "you do not need us yet". The honesty of that answer is the foundation of the relationships that last beyond it.
If you are inside the spreadsheet-or-software question right now and want a working assessment without a sales motion, the conversation is short and useful. Start a Conversation.
Accounting software produces statutory output. ERP automates the workflows of a generic business. Neither is the same as the structured truth a founder needs to run a specific business. That third thing is decision infrastructure, and it is what founder-led firms eventually outgrow SaaS to acquire.
Every six months a founder asks why they need another system when Tally already runs the books. The honest answer is a diagnostic, not a sales pitch. Here is how to run one on your own business.
Tally is the financial system of record. An ERP is the operational system of record. Most founders buy one and assume it is also the other. The confusion costs years.
The contact form takes about two minutes. The reply comes from the founder within two working days.
