When Excel Is Enough (And When It Isn't)

Most businesses run on spreadsheets. Invoices, client lists, project trackers, inventory, hiring pipelines, if it involves rows and columns, it probably lives in Excel or Google Sheets. And for a long time, that's fine. The problems start when it stops being fine, and nobody quite notices until something breaks.

This article is about recognising which situation you're in. Excel is genuinely the right answer more often than software vendors would like you to believe, but there are specific failure modes that are consistent across businesses, and once you hit them a spreadsheet stops solving your problem and starts being your problem.

When Excel Is Actually the Right Answer

Before diagnosing failure, it's worth being honest about what Excel does well. It's flexible, fast to set up, requires no IT involvement, and most of your team already knows how to use it. If your data structure is simple and your team is small, a well-built spreadsheet is a legitimate business tool, not a stepping stone.

The clearest case for staying in Excel is when you already have in-house expertise and a properly structured setup. If someone on your team understands how to build and maintain spreadsheets properly and you have someone who can write VBA to automate repetitive work and build lightweight interfaces on top of your data, Excel can carry a surprising amount of weight. Some businesses have built genuinely sophisticated internal tools this way, and there's no reason to replace something that works well.

The key condition is that last one: internal. The moment a client, supplier, or anyone outside your team needs to see or interact with some of the data, you've crossed into territory Excel wasn't designed for. Of course you can work with hidden columns and hidden sheets, but that gets confusing and fragile quickly. Until then, it's a reasonable choice.

The One-Giant-Table Problem

Most spreadsheet problems trace back to the same root cause: most people don't think in terms of data structure. They think in terms of the answer they want to see: a report, a summary, an overview. They build the spreadsheet to look like that answer rather than to store the underlying data cleanly.

The result is one giant table that does everything: customer names, order history, payment status, contact details, notes, and calculated totals, all in the same rows. It works when the business is small. Then it gets slower. Then it gets bigger. Then someone adds a column and breaks three formulas. Then two people edit it at the same time and one of them loses their work.

The slowness isn't really about file size. It's a symptom of a structural problem — data that was never organised properly to begin with. A well-architected spreadsheet has separate tables for separate things, just like a proper database would. The difference is that most people building spreadsheets have never thought about it that way, and nobody told them to.

The Five Signs You've Outgrown It

Across different industries and business sizes, the same failure modes appear. They're not subtle once you know what to look for.

The sheet is slow.

If opening the file or making a calculation takes noticeable time, that's an important symptom. The root problem is usually a spreadsheet that's doing too much. Storing, calculating, and displaying data all in the same place, with no proper separation.

Multiple people need access at the same time.

This is where Excel breaks hardest. Version conflicts, someone working on a stale copy they downloaded last Tuesday, one person locking the file while three others wait. These aren't edge cases. They're what happens every week in businesses that have grown past a handful of people. Google Sheets reduces this friction significantly, though it introduces its own issues. Not to mention the desire of many companies to not store their data on Google's services.

Different people need to see different things.

This is another case that represents a tough nut to crack. Imagine you have clients who need to see only their own data, employees who work with everything, and managers who need to edit and approve. In Excel, enforcing that requires hidden columns, separate tabs, manual copying, and a level of discipline that most teams won't maintain consistently. It's not a workflow problem. It's a structural limitation of the tool.

You need to expose data to the outside world.

The moment you want a client to interact with something, like fill in a form, check a status, or view a report, you've left spreadsheet territory. You can email exports, share view-only links, or build workarounds, but none of those are the same as giving someone a proper interface to the data they need.

Data integrity is breaking things.

This is the most expensive one, and it often takes a while to show up. In a spreadsheet, nothing stops someone from entering text in a column that should only contain numbers, deleting a row that other rows depend on, or accidentally overwriting a formula. Small errors accumulate quietly. The moment they surface — in a client invoice, a financial report, a stock count — they've usually already cost money. Not in dramatic amounts, but consistently and invisibly.

The Middle Ground: Is There Something Between Excel and a Full Web App?

Yes, and it's worth understanding honestly. Tools like Power BI can sit on top of a spreadsheet and give multiple users concurrent read access with proper filtering and dashboards. Microsoft's Copilot Studio can deploy an AI agent on top of a workbook. If Excel is properly architected with a relational database underneath it, it can behave more like a real application.

These approaches work when you have in-house technical expertise to build and maintain them, and when your requirements stay relatively stable. They're not the right answer when you need client-facing access, role-based permissions that need to be enforced rather than trusted, or a system that will be used by people who aren't technically comfortable. The hidden cost of these solutions is maintenance — they're not simpler than a web app, they're just built in familiar tools. When something breaks, the person who built it needs to fix it, and that person often isn't there anymore.

When You Actually Need a Web App

A proper web application becomes the right answer when you need any of the following.

When different people genuinely need access to different data, and that access needs to be enforced, not trusted. Role-based permissions that actually work — not hidden columns that anyone can unhide — require a proper backend.

When clients or external parties need to interact with your data. Not view a PDF export, not receive an emailed spreadsheet, but actually see their own information and potentially update it.

When data integrity is non-negotiable. A web application validates data before it's saved. A spreadsheet trusts whatever someone types. If incorrect data costs you money — through wrong orders, bad invoices, incorrect reports — you need something that enforces correctness at the point of entry.

When your team has grown past the point where collaboration in a shared file is viable. Not just a larger team, but a team where different people have different workflows, different needs, and different levels of access.

The deciding question is simple: are the problems you're experiencing about the tool, or about how you're using the tool? If your spreadsheet is slow because it's poorly structured, rebuilding it might solve the problem. If multiple people need simultaneous access with different permissions and your clients need a view into the data, no amount of spreadsheet improvement will fix that. Those are architectural requirements, and they need an architectural solution.

A Simple Test

Ask yourself three questions.

Do external parties — clients, suppliers, anyone outside your organisation — need to access or interact with this data? If yes, you need a web application.

Do different internal users need to see fundamentally different things, and does it matter if someone sees data they shouldn't? If yes, you need proper role-based access control, which means a web application.

Has incorrect data in this system ever cost you money, caused a client problem, or led to a wrong decision? If yes, and if the answer happened more than once, you need data validation at the point of entry — which spreadsheets don't provide.

If you answered no to all three, the honest advice is to look at your spreadsheet structure first. A well-built spreadsheet with clean, separated tables can handle more than most people expect. If you answered yes to any of them, you've identified the actual problem — and it's not one that a better spreadsheet will solve.

If you're not sure which category your situation falls into, a short conversation usually makes it clear. Get in touch and we can work through it.