When to turn a spreadsheet into real software: 8 signs

Almost every business I have worked in runs on at least one spreadsheet that has outgrown itself. It started as a list.

Then somebody added a formula. Somebody else added a second tab. A colour code appeared. A few rules arrived that everyone was expected to remember. At some point the business began to depend on it.

Now one person is quietly afraid of touching the wrong cell.

The problem is not that you are using a spreadsheet. The problem is that the spreadsheet became business software without any of the protections business software normally comes with.

The 8 signs it has stopped being just a spreadsheet #

None of these is fatal on its own. Together they describe a file that has quietly been promoted.

1. Only one person can safely edit it #

Everyone knows who that person is. When somebody else needs to change something, they either ask permission or wait for the person who understands the spreadsheet.

That usually means the system depends on knowledge living in one person rather than in the process itself.

2. It contains rules that are not written anywhere #

“Column H stays empty unless it is a renewal.” “Never delete that row.” “If this number changes, remember to update the other tab.”

These are business rules. But instead of being enforced by the system, they live in somebody’s memory.

3. There are several versions of the truth #

Two people download the file. Both edit it. Now there are two versions, both technically valid, and merging them becomes somebody’s afternoon.

The problem is no longer the spreadsheet. The problem is that the business no longer has one reliable source of truth.

4. You make a backup before touching it #

If your first instinct before making a change is to save a copy called something like FINAL_v7_REAL_FINAL.xlsx, you already know the file is fragile.

You are using backups as a substitute for history, permissions and error prevention.

5. Basic management questions take hours to answer #

“How are we doing?” “What expires next month?” “Which customers are overdue?” “What changed since last quarter?”

And the answer means filtering tabs, checking formulas, comparing versions, or asking the one person who knows how it all works. When recurring questions cost hours, the spreadsheet is already doing the job of a business application.

6. Several people need it at the same time #

It worked when one person owned it. Then the team grew. Now several people need to update the same information, and each is worried about overwriting somebody else’s work or editing the wrong copy.

That is usually the process outgrowing the tool.

7. Important changes have no reliable history #

A number changed. A date moved. A status was updated. But nobody knows exactly who changed it, when, or why.

If decisions depend on the spreadsheet, that missing history becomes a real business risk.

8. One mistake could cost real money #

A wrong formula. A missed date. An incorrect amount. A deleted row.

If one small error can create a financial, contractual or operational problem, the business is already treating the file like software. The difference is that nothing is protecting it like software.

Other people collect what happens when this goes wrong. The European Spreadsheet Risk Interest Group keeps a public record of spreadsheet failures that reached court cases, financial statements and the press: eusprig.org/research-info/horror-stories.

Worth ten minutes if you think yours is the only file carrying more responsibility than it should.

Three or four of those together, and you are probably not maintaining a spreadsheet any more. You are maintaining a business system that happens to live inside one.

What changes when it becomes an application #

The point is not that it looks better. It is that the process becomes safer to run, easier to understand, and easier to hand to somebody else.

Take one rule, and look at where it lives.

That is the whole difference. The same business rule either depends on a person remembering it, or on the system enforcing it.

A proper application can also give you:

• several people working at once, without several versions of the truth
• a history of what changed, when, and who changed it
• access levels, so not everyone can see or edit everything
• reminders that fire on their own, instead of waiting for somebody to open the file
• a screen for the questions management asks every month
• validation that refuses impossible or incomplete entries
• and still, when it is genuinely the right answer, an export back to a spreadsheet

The objective is not to get rid of spreadsheets. It is to stop asking them to do a job they were never built for.

Do not start by rebuilding the spreadsheet #

This is where these projects go wrong. The instinct is to recreate every column. Every tab becomes a screen, every exception becomes a feature, the budget grows, the thing gets harder to understand, and eventually somebody asks why they did not simply keep the spreadsheet. That is how these projects die.

Start with the part that hurts. Usually it is one of these:

• one process that produces the same mistake over and over
• one report that eats hours every month
• one approval that gets lost in email
• one deadline somebody has to remember by hand
• one calculation only a single employee understands
• one piece of information several people keep asking for

Build that. Let the spreadsheet keep doing everything else. Once the first piece works it is much easier to see what should move next — and what should stay in the spreadsheet for good.

I have watched more of these fail from scope than from technology.

What this looked like in my own business #

For 14 years I ran La Tejedora Distrito Creativo, a district built inside two former textile warehouses in Cumbayá. More than 50 businesses operated there, with 53 lease contracts behind them.

Thirty of those contracts carried tables that changed the rent every two or three months. Checking one meant finding the contract and opening it. The annual inflation adjustment meant going back to it again. Many ran past 40 pages, so when somebody asked a question, finding the answer usually meant reading the document over.

I tried to keep the important parts under control in a spreadsheet — rents, changes, dates, renewals. But as the contracts moved, keeping that spreadsheet accurate became a business process of its own.

And there was a second problem. Renewing a contract meant finding the previous agreement, recovering what carried over, updating the terms, calculating the new rent, collecting whatever had changed, and preparing the new document. That took anywhere from 30 minutes to two hours.

Those two problems became two different products, and the split between them is the point.

AskRoby: the contracts you already have #

Upload the contracts you already hold and they become a structured portfolio. You see when they expire, when the rent changes, what the important terms are, and what needs attention. You can ask a question about them and see the original page the answer came from.

It solves the first problem: understanding and monitoring what already exists.

RobyContracts: the next contract #

When it is time to create or renew an agreement, upload the previous contract. It pulls out what can be reused, flags what is missing, helps update the terms, and generates the new document. What used to take me 30 to 120 minutes now takes about a minute.

It solves the second problem: producing the next contract instead of rewriting it from scratch.

The two live at www.askroby.io and www.robycontracts.askroby.io. The way AskRoby answers from the page it read has its own article.

Those figures describe my own operation and workflow. They are not a promise about anybody else’s.

The part that matters is that I did not start by deciding to build two applications. I started with two recurring problems that were costing time and creating risk. The software came afterwards.

How I would approach the transition: four questions #

Before anything gets built, four questions decide most of the project.

• What does the business actually depend on this spreadsheet for? Not every column matters equally. Find the parts carrying money, obligations, deadlines, decisions or operational risk.
• Which rules live only in somebody’s head? Those are often worth more than the spreadsheet itself, and they are what the application has to understand and enforce.
• What happens over and over? Repeated checks, calculations, approvals, reminders, reports and data entry are the strongest candidates for automation.
• What should stay a spreadsheet? This matters as much as the rest. If a spreadsheet is still the easiest way to run an occasional analysis or hand numbers to accounting, keep it.

When to leave the spreadsheet alone #

Not every spreadsheet should become an application. If one person edits it, the rules live in their head and that works, and a mistake would be annoying rather than expensive — leave it. If it changes twice a year and nobody struggles with it, leave it. If software would add more complexity than it removes, leave it.

A spreadsheet that works is not a problem waiting to be solved.

The line is crossed when the business depends on the spreadsheet in ways the spreadsheet cannot safely manage: when several people need it, when a rule cannot be enforced, when somebody has to remember what happens next, when management repeatedly needs information that takes hours to prepare, or when one mistake could cost real money.

In short #

• A spreadsheet becomes a business system when the company depends on rules the spreadsheet cannot enforce
• Eight warning signs tell you when that has happened
• The answer is usually not to rebuild the whole thing
• Start with the process carrying the most risk, wasted time or complexity
• Keep spreadsheets for what spreadsheets are genuinely good at
• And if none of the eight signs applies to you, do nothing

Where RobyBusinessSystems fits #

If your business runs on a spreadsheet like this, the first question is not how to replace the spreadsheet. It is which part of the process is creating risk, wasted hours, or complexity nobody asked for.

That is the part I look at. The answer is sometimes a custom system, sometimes a single automated step, sometimes a dashboard, sometimes a workflow between tools you already pay for — and sometimes a better process with no new software in it at all. The shape of that work is on the custom systems page.

The goal is not to add technology. It is to understand the business problem first, then build the right system for it.

Have a spreadsheet your business quietly depends on? Tell me how it works.