Skip to main content
NinjaNext
MVP and product

Replacing the Spreadsheet That Runs Your Business

It started as one tab and now four people depend on it, one of them keeps their own copy, and nobody can say which version is right. Here is how to replace it without losing the thing that made it work.

By NinjaNext TechnologiesPublished 4 min read

Key takeaways

  • The spreadsheet works because it matches how the business actually operates; copy that before changing it.
  • The real failure is usually concurrency and history, not features.
  • Replace one workflow completely rather than every workflow partly.
  • If the new system is slower to use than the sheet, people will keep the sheet.

Almost every business we build custom software for arrives with a spreadsheet, and it is almost always better than anyone admits. It fits the work exactly, it was free, and it was built by the person who understands the job rather than by a committee.

It is also, by the time we see it, the single largest operational risk in the company. Both things are true, and the second one is not a reason to be rude about the first.

When a sheet stops being the right tool

Feature limits are rarely what breaks it. Spreadsheets are extraordinarily capable. What breaks is everything around the edges.

  • Two people edit at once and one person's work quietly wins
  • Somebody keeps a local copy because the shared one is slow, and now there are two truths
  • Nobody can answer who changed a figure, or when, or what it said before
  • The rules live in one person's head and the business stops when they are away
  • A customer or supplier needs to see part of it, and there is no way to show part of it

Those are not spreadsheet problems you can fix with a better spreadsheet. They are the specific things a database does and a file does not: controlling who may change what, recording that it happened, and letting several people work without standing on each other.

Copy the process before you improve it

The strongest temptation, and the most reliable way to produce software nobody uses, is to fix the process while rebuilding it. Someone looks at the sheet, declares the workflow illogical, and designs the sensible version.

The illogical parts are usually scar tissue. That odd column exists because a supplier once sent the wrong thing. That duplicated step exists because an invoice went out twice. You do not have to keep them, but you should find out what each one is for before removing it, because the people doing the work will not thank you for reintroducing a problem they solved in 2019.

The first version should do what the sheet does, in the same order, with the same words on screen. Improvements come after it is in use, when they can be judged against reality rather than argued about in a meeting.

One workflow, all the way

The second trap is breadth. A business with a sheet usually has several, and the obvious plan is one system covering all of them. That plan produces a long project with nothing usable in the middle, and long projects with nothing usable in the middle are the ones that get cancelled.

Take the workflow that hurts most and replace it completely, including the awkward end: the printing, the email that goes out, the thing someone retypes into the accounts package. A workflow replaced to ninety percent leaves the sheet alive, and a sheet that is still alive will quietly take back the other ten.

In the garage management system we built for SwiftFix Auto, the job sheet was the piece worth taking first, because everything else in the business referred back to it. The roles, the customer-facing parts and the rest followed once that was real.

It has to be faster to use, not just better designed

This is the requirement that gets left out of specifications and decides adoption on its own. A spreadsheet is fast in a way custom software often is not: you type into a cell and move on, with no forms, no confirmations and no waiting.

If your replacement takes three clicks and a page load to do what used to be one keystroke, people will be polite about it and keep using the sheet. Keyboard entry, sensible defaults, no modal asking whether you are sure, and the ability to correct a mistake without starting again matter more than anything on the feature list.

The same goes for working when the connection does not. For a workshop floor, a warehouse or a van, a system that stops at a weak signal is worse than paper, which is why that question belongs in the plan rather than in a later phase.

What you gain that the sheet could never give you

Once the work lives in a system rather than a file, things become possible that were not worth asking for before. Customers can see their own records without anyone emailing a file. A new starter can be given access to their part and nothing else. Questions about last quarter can be answered by looking rather than by reconstructing.

None of that is why anyone commissions the work. It is consistently what they value a year later.

Let's build it

Want help putting this into practice?

Tell us what you are building and where you are stuck. We will reply with questions, a suggested approach and next steps.