Back to Blog

Your Spreadsheet Is Your Database. Here's When That Stops Working.

Nearly every small business I walk into has one. It started as a customer list in 2017. Then it got a column for job status, then a tab for the schedule, then a tab for who owes what, then a macro somebody's nephew wrote. Today it is the thing the office opens first every morning, and it is, whether anyone calls it that or not, the company database.

There's nothing wrong with that. A spreadsheet is a perfectly good database for a company of a certain size doing a certain amount of work. The problem is that nobody tells you when you've outgrown it. It doesn't throw an error. It just gets slower, lonelier and less trustworthy until one day a number in it costs you money.

The symptoms

You've probably seen a few of these already:

• Only one person really understands it. If they're on vacation, nobody touches column R.
• There's more than one copy. A crew lead got emailed a version in March. The office has been editing a different one since. Both are "the list."
• The same customer appears three times. "Bob Smith," "Smith, Robert," and "Bob Smith (Mt. Lebanon)," each with a different phone number, one of them right.
• It disagrees with QuickBooks. The spreadsheet says a job is paid. The books say it isn't. Someone spends an afternoon finding out which is true.
• Simple questions take an afternoon. "How much did we do for that property manager last year?" should be a ten-second answer. It's a filter, a pivot, a manual fix, and a shrug.
• It's fragile. A sort without selecting all columns scrambled the phone numbers once. Everyone remembers. Nobody sorts anymore.

Any one of these is a nuisance. Three or four together mean the spreadsheet has become a risk, and it's time to do something, though not necessarily what you think.

What to do before you replace it

The reflex is to go buy software. Resist it for a minute, because most of the pain above is not caused by the spreadsheet. It's caused by the habits around it, and new software inherits habits.

First, figure out what it's actually doing. Most of these files are three things at once: a list (customers, jobs), a calculator (pricing, commissions), and a report (what's due, what's scheduled). Write down which tabs are which. Lists belong in a system of record. Calculators can often stay in a spreadsheet. Reports should be generated, not maintained.

Second, find where each column really comes from. The customer's address originates somewhere: the estimate, the CRM, the phone system. If it's being typed into the spreadsheet by hand from another screen, that column is a copy, and copies drift. Mark every column as either "entered here" or "copied from somewhere else."

Third, kill the extra copies. Put the one real file in SharePoint, OneDrive or Google Drive, share it with permissions instead of attachments, and tell everyone the emailed versions are dead. This costs nothing and fixes the version problem on day one.

Fourth, de-duplicate once, deliberately. Merge the three Bob Smiths. Pick one spelling convention for job names and apply it. Do this with the people who know the customers, because the software can find the near-duplicates but it can't tell you which phone number is current.

Only after that should you decide whether the spreadsheet stays, shrinks, or goes.

What "one source of truth" actually means for a 10-person company

The phrase gets thrown around like it requires a data warehouse. For a ten-person contractor it means something much simpler: for each kind of record, there is exactly one place where it gets created and changed, and everything else reads from that place.

In practice it usually shakes out like this. Customers live in the CRM or the field-service app. Money lives in QuickBooks. Jobs live in whichever tool the crews actually use. People live in your Microsoft 365 or Google Workspace directory. The spreadsheet, if it survives, becomes a view: it pulls from those systems on a schedule, and nobody types into it anymore.

That's the whole idea. Not a new platform, not a migration project. Just a decision about who owns what, and then connections so the other tools stop keeping their own copies. The connections are the part that takes some technical work, but they're a known quantity: QuickBooks, the major CRMs and the major field-service apps all expose ways to sync.

When it's genuinely time to move on

Three situations where the spreadsheet should stop being the owner of a record, no matter how well it's been tidied:

When more than two people edit the same list regularly. When the spreadsheet is the only record of something that would hurt to lose, like which warranty applies to which roof. And when the report you need combines the spreadsheet with another system, because at that point you're maintaining a copy of someone else's data by hand, and that will never stay clean.

None of this means the spreadsheet was a mistake. It carried the business to where it is. It just wasn't designed to be the foundation for the next stage, and the sooner you decide what should own each piece of it, the less painful the move is.