From spreadsheets to a custom system without stopping operations

Spreadsheets are probably the most widely used business management software in the world, and not by accident: they are flexible, everyone understands them and it costs nothing to start. A company can grow a lot on spreadsheets. The problem is not the spreadsheet. The problem is the moment when the operation depends on twenty sheets, on five computers, all saying the same thing.

When that moment arrives, the natural reaction is "we need a system", followed immediately by the fear: "but we can't stop operations to switch". This article is about how that switch gets made without stopping anything.

Why spreadsheets stop being enough

They do not stop all at once. It shows in symptoms that grow little by little:

• Several versions of the same file. "Inventory_final_v3_THIS_ONE.xlsx". Nobody knows which is the right one.
• One person who is the system. Only they know which sheet feeds which and which formula must not be touched.
• Double entry. The same data gets typed into the orders sheet, the inventory sheet and the invoicing sheet.
• Formulas that break silently. Someone inserts a row and a total stops adding up for three weeks.
• No record of who changed what. A number changed and there is no way to know when or why.
• No access from outside. The file lives on one computer; the owner wants to see sales from their phone and cannot.

If you recognize three or more, you are already at that moment. There is a fuller list in signs your company needs custom software.

The problem is not the spreadsheet. It is the operation depending on twenty sheets, on five computers, all saying the same thing.

The most common mistake: wanting to change everything at once

The mental image of a system change is "on Monday we turn off the spreadsheets and turn on the new system". It is the image that scares people, and rightly so: it is how systems projects fail.

A big-bang change forces everything to be ready at the same time, the whole team to be trained on the whole system, and problems to be discovered when there is no way back. It is what happens with licensed ERP implementations that take a year and end with half the team secretly using spreadsheets. We wrote about that comparison in custom ERP vs SAP, Oracle and NetSuite.

The path that works is the opposite: in stages, starting with what hurts most, with spreadsheets coexisting with the system until the system proves it replaces them.

The staged method

Step 1: map which sheets do what

Before building anything, an inventory of the sheets that hold the operation together: which they are, who fills them, where they get their data and who they pass it to. There are almost always surprises: sheets nobody remembered, data entered three times, and a couple of formulas half the company depends on.

That map is the blueprint of the system. There is no need to invent processes: they already exist. They need to be taken out of the sheets.

Step 2: choose the first module by pain, not by logic

The temptation is to start "at the beginning": the product catalog, the customers, the basics. The right criterion is to start with what costs the most today in time or errors. If inventory is what never adds up, start with inventory. If collections are what gets lost, start with collections.

A first module that solves a real pain convinces the team better than any training.

Step 3: build that module with the people who use it

With their words, their order and their exceptions. The system should do what the sheet did, better, without forcing anyone to learn a new vocabulary. When the person who used to fill the sheet sees the first screen and says "oh, it's the same but it doesn't break", the project is going well.

Step 4: run in parallel, briefly

The new module and the old sheet coexist for two or three weeks. The numbers get compared. When they match and the team no longer opens the sheet, it gets retired. Nothing gets switched off before the new thing has proven it works.

Step 5: connect the next one

Each new module joins the previous one. Inventory with sales, sales with invoicing, invoicing with collections. With every connection a double entry disappears, and information starts flowing end to end without anyone copying it.

What stays in spreadsheets

Not everything has to migrate, and that is one of the advantages of doing it in stages. Spreadsheets are a great tool for analyzing, simulating and doing calculations that change every week. What they should not be is the operation's database.

A well-built custom system exports to a spreadsheet in one click. That way the finance team keeps analyzing where they like, but with data that comes from a single source rather than twenty files.

How long it takes and what it costs

The first module, the one that solves the biggest pain, is usually up and running in four to eight weeks. The full system, in stages, in a few months, and each stage gets paid when it is delivered and working. We cover timelines in how long it takes to build an app.

Compared with an ERP license, a system of your own is paid once, is yours, and does not charge per user or per year. And compared with staying on spreadsheets, the real cost of not changing is the hours of double entry, the errors discovered late and the decisions made on stale data.

Frequently asked questions

Will we lose the information we already have in the sheets?

No. Historical data gets imported into the system. It is part of the first module.

What about the team members who "aren't computer people"?

A custom-built system speaks the team's language and does what the sheet did. The learning curve is minimal because there is no generic product to learn, just a tidier version of what they already did.

What if my operation changes next year?

The system changes, because it is yours. With a license you depend on what the vendor allows; with your own system, a module gets adjusted.

Can I start with a single module and stop there?

Yes. If the inventory module solves the problem and everything else works fine in spreadsheets, there is no obligation to continue. You continue when the next pain justifies it.

---

At tēo studio we design and build custom systems exactly this way: mapping what already exists, starting with what hurts most and without stopping operations for a single day. If your company lives in spreadsheets, tell us which one causes the most trouble and we will tell you where we would start.