Running the company on spreadsheets: when they stop being enough and what replaces them

How to tell a spreadsheet has stopped being enough

A spreadsheet does not break overnight. The company grows, the file stays the same, and the work around it grows quietly. These are the signs I hear most often:

• One person “owns the file”. They know which version is current, how the formulas work and what must not be touched. When they go on holiday, everyone else waits or works on a copy.
• The same file exists in several versions. “Orders_2026_final_v3” on the shared drive, a copy in email and a copy on a salesperson’s laptop. Every week someone works out which one is true.
• A person carries data between programs. From email into the spreadsheet, from the spreadsheet into the accounting program, from the program onto a courier label. Every retype is a place for a mistake.
• Nobody knows who changed what. A row disappeared, a price changed, a deadline moved. The spreadsheet does not remember who did it or when.
• Customers call to ask about status. Because there is nowhere for them to check. Someone picks up, searches the file, calls back.
• The month-end report is made by hand. Someone stitches data from several spreadsheets for half a day, and the numbers still disagree.

If you recognise three of these six, the spreadsheet is already costing you staff time, mistakes and customers waiting for a callback.

Why another spreadsheet will not help

The first instinct is to tidy the file: more tabs, macros, locked cells, a shared file in the cloud. That helps for a few months. Then the same problems return, because a spreadsheet has three limits no formula gets around.

A spreadsheet has no roles. Anyone who opens the file can change everything or nothing. You cannot set it up so the warehouse sees only its columns and sales cannot touch prices.

A spreadsheet has no history. You see the state now. You do not see that a job was moved three times and who moved it.

A spreadsheet does not talk to other programs. Accounting, the courier, the shop and the warehouse each hold their own data. The spreadsheet will not fetch it or send it on its own. A person does that.

What replaces the spreadsheet

A system built around your company’s process. It opens in a browser on a computer, tablet or phone, with nothing to install. It differs from a spreadsheet in that:

• Everyone sees what they need. The warehouse has its screen, sales has theirs, the manager sees the whole picture. You set the permissions.
• Every change stays in the history. Who, when, from which value to which. The argument about “who moved the deadline” ends with one click.
• Data is entered once. An order from the form goes to production, to the warehouse, onto the invoice and onto the courier label. From there it moves on its own.
• Statuses move on their own. The customer gets an email or a text when a job changes stage. The manager sees a list of what is late without asking anyone.
• The report is always ready. This month’s sales, machine load, overdue payments. You open it and see it, instead of asking for a summary.

The system is made of modules, meaning self-contained parts: order intake, production, warehouse, customer portal. Each module works on its own and can go live before the next one exists. You do not wait for the whole system to start using it.

How this looks in specific processes is on separate pages: orders and jobs and production and warehouse.

What stays in Excel

Excel does not leave the company. It keeps what one person does for themselves: an analysis for a board meeting, a pricing simulation, a one-off summary. The system exports data to a spreadsheet with one button, so those analyses get easier, because the data is clean and in one place.

What moves to the system is what many people do at once on the same data. Orders, jobs, production, warehouse, customer service. Anywhere a spreadsheet would need roles, history and connections to other programs.

What the move looks like

1. A conversation about how the work looks today. You show me the spreadsheets and tell me who fills them in, what happens next and where it hurts. You do not need a specification.
2. Scope and plan in writing. I write the process down step by step, split the system into modules and give you the order, the timing and the prices. We start with what hurts most.
3. The first module, usually after a month. It replaces one spreadsheet or one stage. The team works on it for real, and their feedback shapes the next modules.
4. Data migration. Data from the spreadsheets goes into the system before each module launches. How to do that without stopping the company is on a separate page.
5. Further modules and handover. You accept each module separately. The code, the documentation and every credential pass to you with each stage you pay for, not only after the last invoice.

How long it takes and how you pay

A small system takes a few weeks, a larger one a few months. You pay for a module after accepting it, usually at month end, not up front for the whole. If you stop halfway, every module you have accepted keeps working and stays yours.

Prices come in writing after the scope is agreed. There is no price list on the site, because a system for a company with three people in the warehouse and a system for a company running production on two shifts are two different scopes. What drives the price is covered in the guide on custom software.

If you want to see how this would look for you, describe in the form below what you run in spreadsheets today. I will get back to you.