Internal tools for a small business, and when to stop using Excel

Every small business runs on internal tools. The question is never whether to have them, because the stock sheet, the client tracker and the pricing calculator are already doing that job. The question is whether the current ones still cost less than they save, and that is a question most companies answer years late.

This note is the general version. Several of the specific cases have their own write-ups and are linked below, but the decision underneath them is the same one, and it is worth seeing on its own before you go looking at a particular system.

The tools you already have

A spreadsheet is a real internal tool. It is fast to create, free at the point of use, requires no deployment, and can be changed by the person who needs the change without asking anyone. Those are genuine engineering virtues and they are the reason spreadsheets win, not a sign that nobody thought about it properly.

They also have a documented reliability problem, and it is worth being precise about it rather than gesturing at it. Raymond Panko's review of the field, Spreadsheet Errors: What We Know. What We Think We Can Do, opens with the conclusion that fifteen years of studies agree that spreadsheet errors are, in his words, "both common and non-trivial". His other finding is the uncomfortable one: of the techniques proposed for reducing them, only cell-by-cell code inspection has been demonstrated to work. Not training, not care, not being senior. Line by line review, which nobody does to a spreadsheet.

The practical reading is not that spreadsheets are bad. It is that a spreadsheet carrying a number somebody makes a decision on has no safety net, and the size of the mistake it can hide scales with how long it has been in use.

Four signs the spreadsheet has stopped paying for itself

These are the ones that show up consistently. One of them is not enough. Two together usually is.

• More than one person edits it at once. Concurrency is where a spreadsheet stops being a tool and starts being a negotiation. Versions named final-2 are the symptom.
• You cannot answer what changed and who changed it. No history means no audit, and no ability to find the moment a number went wrong.
• Somebody spends hours a week re-keying between two of them. That is not a spreadsheet problem, it is an integration problem wearing one.
• A wrong cell costs real money. Pricing, stock, payroll and anything sent to a client or a regulator belong in this category.

Notice that none of these is about size. A ten thousand row sheet that one person owns and reads is fine. A two hundred row sheet that four people edit and that sets prices is the dangerous one.

What to build first

When it is time, the temptation is to build the impressive thing. The impressive thing is almost never the one that pays back. Sequence matters more than scope here, and the order below holds across most small businesses.

The export line is not a throwaway. The fastest way to lose a team's trust in a new internal tool is to make their data harder to get at than it was in the sheet, and the fastest way to keep it is to prove on day one that they can still get everything out.

Build, buy, or neither

Three outcomes are available and only one of them involves writing software. Buying an off-the-shelf product is usually cheaper and always faster, and it is the right answer whenever your process is ordinary. The full comparison is in custom software vs off the shelf, decided in the right order, and the honest signals for each are in signs you need custom software, and signs you do not yet.

The third outcome, doing nothing but doing the spreadsheet properly, is underrated. Locking the formula cells, giving one person edit rights, and adding validation is an afternoon of work that removes most of the risk in a sheet that is otherwise fine. If the process is still changing every week, this is actively the right answer, because freezing a moving process into a schema is how you end up rebuilding twice.

Where the specific cases live

Most small businesses arrive at this from one of a few directions. If the problem is that the numbers take a day to assemble every month, that is reporting automation, honestly scoped. If it is stock, the tipping point is covered in when a stock spreadsheet starts costing more than it saves. If you have already decided to move and the worry is losing years of records, the sequence is in migrate from spreadsheets to a database without losing the history.

The part that is not a software problem

An internal tool encodes a process, which means it also encodes whoever currently owns that process and whatever they have not written down. If two people disagree about how a job is done, the build will surface that disagreement and then stall on it, and no amount of engineering resolves it. Settling those questions first is cheaper than discovering them in a sprint review.

The same discipline applies to the data itself. A new system inherits the quality of what you put into it, and a tool built on a sheet where the same customer appears four different ways will produce four different answers with more confidence than the sheet did.

Worth borrowing from the sales side here: BDG Labs argues in CRM hygiene for small sales teams that the rules governing what goes into a system matter more than the system itself. That is exactly right, and it generalises past CRM to every internal tool a small company runs.

An honest limit

If you are reading this hoping for a threshold, a headcount or a revenue number above which you should build, there is not one, and anybody offering you one is guessing. The signals above are the real test, and they are situational. A four person company with a pricing sheet that four people edit needs this more than a forty person company where one operations lead owns everything and it works.

The cheapest next step is usually not a build at all. It is spending an hour writing down which decisions currently depend on a spreadsheet number, and who would notice if that number were wrong. Most companies find one or two entries on that list they are not comfortable with, and that is the tool worth building.