Let's start with something you won't hear from most database developers: spreadsheets are brilliant. Excel is one of the most successful pieces of software ever written, and for a lot of jobs it's exactly the right tool. We're not here to tell you spreadsheets are evil.
We are here to tell you when they stop being the right tool — because we've spent since 1998 rescuing businesses from spreadsheets that quietly became the company's central nervous system, and there's a recognisable pattern to it.
When a spreadsheet is genuinely fine
Keep using a spreadsheet when:
- One person owns it. A cash-flow forecast the FD updates, a price calculator, a one-off analysis. Single author, no sharing headaches.
- The data is throwaway or short-lived. This quarter's event plan. Next month's rota draft.
- It's actually about calculation. Modelling, what-ifs, budgeting. This is what spreadsheets were built for and they remain unbeatable at it.
- The structure is flat. One list, one sheet, no relationships between things.
If that's your situation, stop reading, get back to work, and don't let anyone sell you a database.
The warning signs it isn't fine any more
Businesses rarely decide to run on spreadsheets. It happens by accretion — a list becomes a system, the system becomes critical, and one day you notice the whole company depends on Orders_v7_FINAL_use-this-one (2).xlsx. The warning signs:
Version chaos. Multiple copies of "the" spreadsheet circulating by email, and nobody is certain which is current. If you've ever spent a meeting arguing about whose numbers are right, you're here.
More than one person needs to edit at once. Shared spreadsheets have improved, but simultaneous editing of a structured business record — with people overtyping each other's rows — is still a reliable source of quiet data loss.
Relationships between things. The moment you're copying a customer's details onto every order row, you have relational data in a flat tool. When that customer changes address, you now need to fix it in 47 places, and you'll fix it in 40.
Fragile formulas nobody dares touch. There's one sheet only Dave understands, Dave built it in 2016, and Dave is retiring. Every business has a Dave sheet.
No history and no accountability. Someone changed a price. Who? When? What was it before? A spreadsheet shrugs.
Retyping into other systems. If data from the spreadsheet gets keyed into your accounts package, your email tool, or a supplier's portal, you're paying humans to be an integration.
Three or more of these and the spreadsheet isn't saving you money. It's costing you money in a currency you're not tracking: errors, duplicated effort, and decisions made on stale numbers.
What actually changes with a database
A Claris FileMaker system — the platform we build on — changes a few specific things, and it's worth being concrete about them rather than hand-waving about "efficiency":
One version of the truth. The data lives in one place, on a server. Everyone sees the same records at the same time. The v7_FINAL problem simply ceases to exist.
Structure that matches your business. Customers, orders, jobs, invoices — each stored once, linked properly. Change the customer's address and it's changed everywhere, because it was only ever stored in one place.
Rules the software enforces. Required fields, valid date ranges, "you can't invoice a job that has no order." The database refuses bad data at the door instead of letting you discover it at year end.
Different views for different people. The warehouse sees a picking list. The MD sees a dashboard. Sales sees the customer history. Same data underneath — no more maintaining three spreadsheets that are supposed to agree.
An audit trail. Who changed what, and when. Boring until you need it, priceless when you do.
Connections to everything else. A FileMaker system can talk directly to Xero, your website, Mailchimp, and other systems through their APIs — we cover this in our API integrations work. One real example: we rebuilt a holiday-tracking export for a construction workforce client that took 10 minutes to run as it stood. Afterwards it took about ten seconds. Nobody misses the old version.
The migration path (less scary than you'd think)
The good news about spreadsheet-based businesses: the data already exists and the process already works. You're not inventing anything — you're re-housing it. A typical path with us:
- Free consultation. We look at the spreadsheets, ask how they're actually used (which is never quite how anyone describes it), and tell you honestly whether a database is justified. Sometimes it isn't, and we'll say so.
- Start with the worst one. You don't migrate everything at once. Pick the spreadsheet causing the most pain and replace that.
- Clean and import the data. The migration itself usually surfaces years of duplicates and inconsistencies. Cleaning them up is part of the job and weirdly satisfying.
- Run in parallel briefly, then switch. A short overlap builds confidence; a clean cut-over date avoids running two systems forever.
- Extend when ready. Once the first module is live, adding the next one is quicker — the foundations exist.
You own the system you've paid for, we invoice monthly for completed work, and you can stop whenever you like — details on our how we charge page.
An honest summary
Spreadsheet: right tool for calculation, modelling, and single-owner lists. Database: right tool for shared, structured, long-lived business records that other systems depend on. Most growing businesses need both — the trick is noticing when a spreadsheet has drifted from the first job into the second.
If you suspect yours has, we do a free initial consultation and we're happy to tell you if a spreadsheet is still the right answer. There's more on our approach at replace your spreadsheets.
Call 0330 113 0958 or email info@flaresoftware.co.uk.