Running the business on spreadsheets: when it's time for a real app
Spreadsheets are the first database of almost every company. A client list in one tab, orders in another, a few formulas gluing it together, and one person who understands it all and maintains it in the evenings.
For a couple of years this works fine. Then cracks appear quietly, and it helps to name the common ones.
The signs the sheet has outgrown itself
- Two people edit the same file and one overwrites the other's changes.
- Nobody knows which copy is current. Someone keeps a "final_v2_NEW" file on the desktop, and a decision gets made from stale data.
- The same fact lives in three files and the files disagree.
- The one maintainer is on holiday and nobody dares touch the formulas.
- You repeat the same manual ritual every week: copy a range, paste it into an email, reformat, send.
- There is no history. When a number looks wrong, nobody can say who changed it, when, or what it was before.
One of these is livable. Two or three together usually mean the business is paying real money for manual work and silent errors, it just never shows up as a line item.
What a proper app changes
An application is the same data with rules attached. The rules are the value:
- One record per fact, validated at the moment of entry. A bad phone number gets rejected once, at the form, instead of surviving in forty exported reports.
- Access control. People see and edit what their role allows, so the "please don't touch tab 4" emails stop.
- An audit trail. Every change has an author and a timestamp, so disputes about who did what end in minutes.
- Scheduled automations for the recurring steps: imports, reminders, export runs. The weekly copy-paste ritual becomes a job nobody thinks about.
None of this needs exotic technology. A plain Laravel app with PostgreSQL behind it covers most cases a spreadsheet is straining to cover.
How the move actually happens
The failure mode of these projects is building everything at once and switching off the sheet on day one. What works better reads like this:
- Inventory the sheet before writing code. Which tabs are load-bearing, which are abandoned, which formulas encode real business rules; a good chunk is decoration and doesn't need a rebuild.
- Keep the mental model. If the team thinks in "orders" and "clients" with a specific status flow, the app should use those words. New vocabulary means retraining everyone and quietly fighting your own users.
- Build the smallest useful core: the two or three workflows that eat the most hours, rather than the whole feature universe.
- Import the data with validation, and expect the import to be ugly. Duplicate clients, dates in six formats, records pointing at nothing. A dry-run import that reports problems without writing anything saves a bad first week; we described that technique in the CSV imports article.
- Run both systems in parallel for a short, agreed period, with the app as the source of truth by the end of it. Then stop editing the sheet. "We'll keep the sheet too, just in case" is how migrations die a year later with two divergent systems.
What stays in the spreadsheet
The migration doesn't kill the tool. Sheets remain good at quick analysis and experiments that aren't worth software yet. A healthy setup after the move goes one way: the app holds the operational data, and people export from it when they want to play with numbers. The reverse direction, sheets feeding the app without controls, created the original problem.
The honest cost
A first version of such an app usually takes weeks, not months, when the scope stays at "core workflows". What costs extra is scope that grows during the build ("also add a dashboard, user groups, and the CRM part") and data cleanup that nobody budgeted. Both are controllable when the client and the studio name them early.
The trigger to act is simple. When the spreadsheet starts costing hours a week and making silent errors, the app pays for itself. Before that point, the sheet is the right answer.