Spreadsheet Hell

It started as a simple tracker. One tab, a dozen rows, built in an afternoon by someone who just needed to keep on top of jobs. It worked — so it grew. A tab for pricing. A tab for suppliers. A column for status, then another for the status the first column doesn't quite cover. Conditional formatting nobody can explain. A formula referencing a tab that was deleted in 2023 and still, somehow, returning a number.

Now it runs a meaningful part of the business. It's on someone's desktop, or a shared drive, in a file called something like Job Tracker FINAL v4 (updated).xlsx. And there is exactly one person who really understands it. When they're on leave, things slow down. When they eventually resign, it will be a genuine problem — and everyone knows it, and nobody has said it out loud.

That's spreadsheet hell. It's not a technology problem. It's the point where a tool that was perfect for one person became infrastructure for a team, without anyone deciding it should.

The obvious cost is time — the hours each week spent copying data between the spreadsheet and the accounting system, re-sending the file because someone edited the wrong version, rebuilding the report that broke when a column moved. Those hours are easy to underestimate because they're spread thin across a lot of people.

The bigger costs are the ones that don't show up on a timesheet. Nobody trusts the numbers, so decisions get delayed while someone "just double-checks." Two people quote the same client differently because they were working from different copies. A margin error survives three months because there's no audit trail and no way to see who changed what. And the business can't grow the process — hiring two more people doesn't help when the bottleneck is a file that only one person can safely touch.

Then there's the risk sitting underneath all of it: no version history worth the name, no backup discipline, no permissions. One bad paste, one corrupted file, one departure.

It's worth being clear, because this is the part most software companies skip: spreadsheets are brilliant. For modelling, forecasting, one-off analysis, and anything where the shape of the problem changes every time you look at it, nothing beats a blank grid. We use them daily. We are not here to tell you every spreadsheet is a failure waiting to happen.

A spreadsheet is the right tool when one person owns it, when the calculation matters more than the record, when it's genuinely temporary, or when you're still working out what the process even is. That last one is important — building software around a process you haven't settled yet is a reliable way to waste money. Sometimes the honest advice is to keep using the spreadsheet a while longer and get the workflow right first.

The trouble starts somewhere else entirely: when the file stops being a calculation and becomes the place the business keeps its truth.

More than one person needs it at once. The moment you're coordinating who has the file open, or reconciling two versions, you're using a single-player tool for a multiplayer job.

A mistake in it costs real money. If a mistyped cell can send an incorrect invoice, misprice a quote, or lose an order, the process needs validation and an audit trail — things a spreadsheet fundamentally can't give you.

Someone's job is maintaining it. Not using it. Maintaining it — tidying, reconciling, chasing people to fill it in. That's a salary being spent on the tool rather than the work.

You're copying data between systems by hand. Out of the spreadsheet into Xero, out of the CRM into the spreadsheet. Every manual copy is a place errors enter and time disappears.

Only one person really understands it. The key-person risk one. If you're relying on someone not leaving, that's not a process — it's a hope.

One of these is normal. Three or more, and the spreadsheet has become infrastructure, and it's worth costing what that's doing to you.

Crossing that line doesn't automatically mean commissioning software. There are three realistic routes, and the cheapest one that solves the problem is the right one.

Automation is the first thing to consider, and often the answer. If the pain is data being re-typed between tools you already pay for, connecting those tools directly can remove most of it without building anything new. Workflow automation and API integration handle a surprising share of what looks like a software problem, usually for a fraction of the cost.

Off-the-shelf software is the next question: does a product already exist for this? For standard problems — accounting, CRM, project management, basic scheduling — it almost certainly does, and it will be cheaper and better-supported than anything custom. If a product fits your process without contortions, buy it. We'll tell you when we think that's the case.

A custom application earns its place when the workflow itself is the thing that needs a home — when your process has rules, stages, and exceptions that generic tools force you to work around, and when those specifics are part of how you compete. That's when a custom web application stops being an expense and starts being an asset.

Here's the part people don't expect: that ugly, sprawling, slightly frightening file is the single most valuable thing you can bring to a first conversation. It's a working record of how your business actually operates — not how a policy document says it does. Every workaround column, every colour-coded status, every note in row 400 is a requirement someone discovered the hard way.

So we read it before we design anything. The tabs show us the entities. The manual steps show us what to automate. The columns nobody fills in show us what doesn't matter. And the data comes across into whatever gets built, rather than being stranded in the old file.

If any of this sounded like your business, the useful next step isn't a quote — it's a conversation about whether the fix is an automation, a product you can buy, or something built. We'd rather tell you it's the cheap option. Start with custom software development if you want to see how we approach it, or just send us the story of the spreadsheet.