Every business has one. The spreadsheet that tracks service contracts, or equipment at customer sites, or who is booked on which course. It started as a quick fix years ago. Now it has twelve tabs, colour codes only one person understands, and a rule that nobody sorts column D.
Spreadsheets are brilliant. They are flexible, everyone knows how to use them, and they cost nothing. That is exactly why they end up running things they were never built for.
Signs it has outgrown itself
You do not need to replace every spreadsheet. But it is time to look at this one if:
- More than one person edits it, and you have had a "who changed this?" moment
- People keep their own copies, so there are three versions of the truth
- It needs to remind someone of something, like a contract renewal or a certificate expiry, and it cannot
- Information gets copied into it from another system, and back out again
- One person is the only one who really understands it, and they are going on holiday
If three or more of those apply, the spreadsheet is no longer a tool. It is a system, just a fragile one.
What the replacement should keep
The biggest mistake is replacing a spreadsheet with something that takes away what people liked about it. Before building anything, write down what works:
- Seeing everything on one screen
- Filtering and sorting quickly
- Exporting when someone needs a report
- Changing things without asking IT
A good internal tool keeps all of that, and adds what the spreadsheet could never do: proper permissions, a history of who changed what, reminders that actually send, and connections to your other systems.
Build around the work, not the columns
Do not just turn each column into a field. Look at what people actually do with the sheet.
Take a service contract tracker. The columns might be customer, serial number, start date, end date, price. But the real work is: "show me what renews in the next 60 days," "what does this customer own," and "remind the account manager before it lapses." The tool should be designed around those jobs, with the data underneath.
That shift, from a list of columns to a list of jobs, is what makes the new tool feel better instead of just different.
Keep it small at first
The first version should do the three or four things people use the spreadsheet for most. That is it. Launch it, have people use it for a few weeks, then add what they ask for.
Resist the urge to put every possible feature in version one. Tools that try to do everything on day one take longer to build and are harder to learn, and people quietly go back to the spreadsheet.
Bring the history with you
Move the existing data across, cleaned up, so the new tool is useful from the first day. Nobody wants to start from an empty screen. Keep the old spreadsheet read-only for a while so people can check it if they need to, then retire it.
You should own it
Whatever replaces your spreadsheet, make sure you own the code and the data. Internal tools tend to last for years. You do not want to be locked into one vendor for something your business depends on daily.
That is how we build them: on tools and accounts you control, with the source handed over, and support available because it is useful, not because you are stuck.
Planning work like this? Part of it may qualify for Canada's SR&ED tax credits. Here is how SR&ED applies to custom development.