Category: The Techy Side of Everything Reading time: ~5 min Published by: Brendan Erofeev, The Techy Side
Someone pushed back on one of my LinkedIn posts last month.
I'd been talking about what happens when a business outgrows its spreadsheet and starts looking for something new. Their response: "You can do exactly the same thing in a spreadsheet."
And I said: "How did you go scaling that?"
Because that's the real question. Not whether the spreadsheet works, it does, and for a long time it works really well, but what happens when the business has grown past what it can carry.
The Natural Path Every Business Takes
Almost every business starts in a spreadsheet. That's not a bad thing. It's the right tool for where you are.
It's flexible. Everyone knows how to open it. You can build what you need without committing to a system, without a setup process, without a monthly subscription. You can make it do roughly what you need it to do, and you can change it yourself when your needs change.
The problem isn't the spreadsheet.
The problem is when the business grows past a certain size or complexity, and you're still trying to run it on infrastructure that wasn't built for where you are now.
I help people over that lump a lot. And the thing I've noticed is that by the time most people realise the spreadsheet isn't working anymore, they're already well inside the problem. The data's inconsistent. The formulas are breaking. Someone's maintaining a version nobody else can find. It takes half a Friday to pull a report that still isn't quite right.
And then they start looking for the next thing.
The Question Nobody Asks Before They Commit
Here's where it gets interesting.
You've decided you need something new. You go looking for software. You find something that looks like it does everything, it's got dashboards, it's got reports, it's got a clean interface. You sit through a demo and the numbers look great.
You sign up. You migrate everything across. You spend a couple of months getting everyone across it.
And then, six months later, you need to compare your project data against your accounting system to figure out whether a job was actually profitable. And you can't. Not easily. Not without someone manually pulling data from two different places and trying to line it up in, you guessed it, a spreadsheet.
This is the thing I strike consistently when I come into a business that's having reporting problems. It's not that the software doesn't work. It's that nobody asked the right questions before committing to it.
Three Questions Worth Asking Before You Sign Anything
Software is typically a 3-7 year commitment once you factor in setup, training, migration, and the operational habits that build up around it. The questions below take maybe twenty minutes to work through. They can save months of headaches later.
How does this system report out?
Not just "does it have a reports tab." Ask what it actually exports. Ask whether it can connect to something like Power BI or another data service. Ask what the data looks like when it leaves the system. A system that can only talk to itself is useful up to a point, and that point arrives faster than you'd think.
How does it talk to your accounting system?
This is the one that catches people. Everything looks fine until you need to contrast what's happening in your project or operations software against what's happening in your accounts. That's when the gaps appear. Find out before you sign whether there's a real integration or just a manual export.
Where do your timesheets go, and what do they actually feed into?
For labour-intensive businesses, this is probably the most important one.
Labour is your biggest cost and your biggest revenue driver. Most systems will get your payroll out on time, that part works. But payroll accuracy and labour cost attribution are two different things. You can pay everyone correctly every single week and still be running well over budget on a job because the timesheet data isn't flowing anywhere useful.
You need to know whether the hours feed into cost attribution across your jobs, not just into payroll. Because if they don't, you're missing half the picture.
What Usually Happens When These Conversations Don't Happen
I'm not saying this to make anyone feel bad about the software they're already in. Most of the time, the decision was made without this information, not because anyone was careless, but because nobody laid it out clearly before the contract was signed.
The businesses I come into with reporting problems didn't get there because they made a bad decision. They got there because they made a reasonable decision with incomplete information, and by the time the gaps showed up, they were too embedded to easily change course.
So the work becomes: how do we make what you've got talk to what you need, and where's the cleanest path to get there.
That's a solvable problem. It's just more expensive to solve than asking the questions upfront would have been.
Back to the Spreadsheet
The person who commented last month wasn't wrong. You can do a lot in a spreadsheet. For a long time, you probably should.
But "how did you go scaling that?" is a genuine question. Because scaling is where it breaks. And the businesses that are in the most trouble aren't the ones that stayed in their spreadsheets too long, they're the ones that moved too fast into something new without understanding what they were committing to.
The spreadsheet question is really a decision-making question. Not "should I still be in a spreadsheet" but "when I move, am I moving to something that can actually carry where the business is going?"
That's worth thinking through before you sign anything.
If you're somewhere in the middle of that transition, you know you need to move but you're not sure what the right next step looks like, feel free to reach out. It usually starts with a pretty straightforward conversation.
Brendan Erofeev is a technology implementation consultant working with construction, trades, and small-to-medium businesses across Australia and New Zealand.
