When to replace your spreadsheets with a custom system.

Spreadsheets are not the problem

Let us be clear first: a spreadsheet is often the right tool. When a process is new, changing every week and owned by one person, nothing beats a sheet for speed. Building custom software too early locks in a process before you understand it. A lot of good systems we have built started life as a well-loved spreadsheet that proved what the business actually needed.

The problem starts when a sheet quietly changes jobs. It stops being a personal tool and becomes the shared operating system of a team, and it was never designed for that.

Seven signs a spreadsheet has outgrown its job

1. Several people edit it at once, and someone keeps overwriting someone else. Shared sheets handle simultaneous editing better than they used to, but they cannot stop two people from making conflicting decisions in different rows.
2. There are copies. "Sales tracker FINAL", "Sales tracker FINAL v2", a version on someone's laptop and another in a chat. Nobody is sure which one is true.
3. The same data is typed twice. An order goes into the sheet, then into the invoicing tool, then into a delivery list. Each copy is a chance for a typo.
4. Only one person understands the formulas. If they are on leave, the monthly report waits for them.
5. You need to know who changed what, and you cannot. Version history shows edits, but not the business reason behind them, and it is painful to search.
6. Customers or partners need a view of it. Sharing the whole sheet exposes too much; making filtered copies brings back the copies problem.
7. Something needs to happen automatically. A reminder when a renewal is due, a message when a booking is confirmed, an alert when stock is low. A sheet records facts; it does not act on them.

If three or more of these are true, the sheet is costing you more than it saves. The cost is just spread across many small moments, so it rarely shows up on a budget.

What a first system should do

The most common mistake is trying to replace everything at once. A good first version is deliberately narrow:

• One source of truth for one core record. Customers, bookings, members, orders: pick the record the business revolves around and give it a proper home in a real database.
• Forms that prevent bad data. Required fields, dropdowns instead of free text, dates that are actually dates. Most spreadsheet pain is inconsistent data, and the cheapest fix is not letting it in.
• Roles and permissions. Staff see what they need, managers see more, and external people see only their own records.
• A history of changes. Who changed a status, when, and ideally why.
• The two or three automations that hurt most. Usually a confirmation message, a reminder and a daily summary.
• An export button. People will still want to analyse numbers in a spreadsheet, and that is fine. The difference is that the sheet becomes a read-only copy, not the master.

What a first system should not do

• Copy every column. Old sheets collect columns nobody uses. Moving to a system is a good moment to ask which fields anyone actually reads.
• Automate a process nobody agrees on. If two managers run the same process differently, software will not settle the argument. Agree the process first, then build it.
• Build reports before there is data. Dashboards are easy to add once the records are clean. Designing them first is guessing.

Custom build or off-the-shelf tool?

Off-the-shelf tools are a great answer when your process is close to the standard one: a typical sales pipeline, a typical helpdesk. You get years of product work for a monthly fee. A custom system earns its cost when the way you work is part of what makes you different, when you would spend more on workarounds and integrations than on building, or when you need to combine several things (bookings, memberships, payments, messaging) that no single product does well together.

A useful test: list the five things your team does most often in a day. If an existing product does four of them well, use it. If it does two, and the rest live in side spreadsheets, that is the case for building.

Moving over without stopping the business

1. Clean the data before importing it. Remove duplicates, agree spelling for categories, fix dates. A day of cleaning saves months of confusion.
2. Run both in parallel for a short, fixed period. One or two weeks, with a clear end date. Open-ended parallel running means nobody commits to the new system.
3. Move one team or one process first. Learn from them, fix the rough edges, then move the rest.
4. Make the sheet read-only on switch-over day. If it can still be edited, it will be.
5. Collect feedback in the first month and act on it fast. Small fixes in week one decide whether people trust the new tool.

The real return

The return on replacing a spreadsheet is rarely one big saving. It is many small ones: fewer messages asking "is this up to date?", no more re-typing, a renewal that is not missed, a manager who can see the week's numbers without waiting for a report. Add those up across a team over a year and they are usually worth far more than the build.

This is the kind of work we describe under Systems. If your team is running on a sheet that has outgrown its job, tell us about it.