When to stop running your business on spreadsheets
A spreadsheet is not the problem. A spreadsheet that six people edit and one person understands is.
Replace a spreadsheet with an internal tool when more than two people edit it, when errors in it cost money, or when someone spends more than four hours a week maintaining it. At Indian salary levels, four hours a week of a mid-level employee is roughly ₹1.5–2.5 lakh a year — usually more than half the cost of the build.
Key takeaways
- Count the hours before you scope anything; the business case is almost always in the timesheet.
- Concurrency and audit trail are the two things a spreadsheet can never give you.
- Scope phase one to one process and one team, or it will not ship.
- Rollout, not engineering, is where most internal tools fail.
Spreadsheets are extraordinary software. They are also the reason a lot of Indian businesses have an operations process that only one person fully understands, and that person is now unable to take leave.
The four signs it is time
- 01More than two people edit it. Concurrent editing in a shared sheet is a merge conflict with no resolution mechanism.
- 02Errors in it cost money. A wrong figure in a pricing sheet is a discount you did not intend to give.
- 03Someone maintains it as a job. Four hours a week of a ₹9 lakh employee is roughly ₹1.8 lakh a year in salary alone.
- 04You cannot answer 'who changed this and when'. No audit trail means no accountability and, in regulated sectors, no evidence.
Doing the arithmetic honestly
Write down the process, count the hours each person spends on it per week, multiply by their fully loaded cost, and annualise. Then add the cost of the errors — the wrong dispatch, the missed follow-up, the invoice raised twice. Most internal tool builds we quote at ₹3–8 lakh are replacing ₹4–12 lakh a year of manual work.
What phase one should contain
One process. One team. The screens that team uses daily, and nothing else. Not the reporting module, not the mobile app, not the integration with the system nobody has agreed on yet. Ship something the team uses within eight to twelve weeks, then let the next phase be shaped by what they ask for once it is real.
Why these projects fail
- Scoped from a management description of the process rather than from watching it happen.
- Built for everyone, so it fits nobody, and the team keeps a shadow spreadsheet anyway.
- Rolled out in one go with no pilot, so the first bad week destroys confidence permanently.
- No owner after launch. A system that mirrors a live process needs a budget for change, or it drifts out of use in a year.
The engineering is rarely the hard part. If you take one thing from this page, take the pilot: two to four weeks running in parallel with the old process, with the people who will use it, before anyone switches anything off.