Admin dashboards and internal tools

The short version

Most small businesses do not run on their accounting package. They run on a spreadsheet — the one with the color coding, the tab nobody touches, and the formula in column P that only Ray understands. It works, right up until Ray is out sick, two people edit it at once, or somebody sorts one column without the others.

• A shared spreadsheet is a single point of failure with a person attached to it.

• The replacement is not a bigger spreadsheet. It is a back-office system with real permissions, real search and a record of who changed what.

• A focused internal tool usually starts around $5,000 and takes two to four weeks.

• We build these on Filament, which is why they land fast — the boring parts are already solved and we spend the budget on your rules.

• The success test is not features. It is whether your team stops keeping a private copy on the side.

What goes wrong when a spreadsheet becomes the system

Not the spreadsheet. Spreadsheets are superb at exploring numbers. The problem is what happens when one becomes the place where the business's state is stored: it has no idea who is allowed to see what, no memory of what it looked like yesterday, and no way to stop someone typing "Pendng" into a column three other formulas are reading.

The failures are always the same four:

• Concurrency — two people edit, one wins, nobody is told.

• Validation — nothing stops a date in a price column or a customer name spelled three ways.

• Permissions — everyone who can see the job list can also see the margins and the payroll tab.

• History — when a number is wrong, there is no way to find out when it went wrong or who changed it.

The cost of all this is rarely a dramatic incident. It is a slow tax: the weekly reconciliation, the argument about which version is current, and the two weeks of shadowing a new hire needs before they can be trusted with the file.

What makes an internal tool people actually use

The bar is higher than it looks, because staff can always go back to the spreadsheet. An internal system earns its place by being faster than the thing it replaced on the first day, not by being more capable in six months.

In practice that means:

• Search that finds a customer from half a surname or a phone number, at the top of every screen.

• Lists you can filter and sort the way you actually think about the work — by status, by owner, by "due this week", by "waiting on us".

• Bulk actions, because the real job is usually thirty records at once, not one.

• Export back out to a spreadsheet, in one click. Refusing to let people export is how you lose them.

• Roles and permissions — the workshop sees jobs, the office sees jobs and invoices, the owner sees margins.

• An audit trail: who changed this record, when, and what it said before.

• A dashboard that answers the three questions you open the system to ask, without a report builder.

Speed is a feature in its own right, and an underrated one. A screen your team opens forty times a day needs to load immediately; half a second of lag is what turns a system people use into a system people avoid, and no feature list makes up for it.

That last point is where most internal tools go wrong. A dashboard should not be a wall of charts. It should be the three numbers you would otherwise ask someone for, above a list of the things that need a decision today.

What an admin dashboard costs

A focused internal tool or admin dashboard usually starts around $5,000, and most land inside two to four weeks. Larger back-office systems — several linked areas, multiple roles, integrations out to accounting or shipping — run higher, and we quote them in writing after a short discovery call.

These land cheaply for a specific reason: we build them on Filament, a mature admin framework for Laravel. Tables, forms, filters, file uploads, roles and the rest are already solved and already tested, so almost none of your budget goes on plumbing. What you pay for is your business's rules, which is the only part nobody else can supply.

When to keep the spreadsheet

When it is genuinely a spreadsheet job. Modeling, forecasting, one-off analysis and anything where the shape of the question changes every time — a database will make that harder, not easier.

Keep it, for now, when:

• One person uses it, and no one else needs to see it.

• The process it holds is still being invented and changes most weeks.

• It is a scratchpad, not a record — nothing downstream depends on it being right.

• It is fewer than a couple of hundred rows and stays that way.

The moment to move is when the file becomes something other people depend on: when a second person needs it, when a customer-facing promise is based on it, or when being wrong for a day would cost real money. That is the line, and it is usually crossed long before anyone notices.

Getting your data across without losing a week

We import it, and we do it early, not at the end. The first import usually happens in week one of the build, because the real state of your data is the thing most likely to change the design — duplicate customers, three spellings of the same supplier, dates stored as text.

What we do with what we find:

• De-duplicate and normalize, with the rules agreed with you rather than guessed at. Database design and data cleanup goes into how that works.

• Keep the messy original as an untouched archive, so nothing is ever unrecoverable.

• Re-run the import repeatedly during the build, so launch day is a rehearsal you have already done.

• Keep the old file readable for a month after launch, so nobody feels the floor disappear.

The team is trained on the real system with the real data before it goes live. Training on a demo dataset is how you get a month of "the system is wrong" tickets that are actually questions.

What you own at the end

The code, the repository, the database and the hosting account, all in your name. Filament and Laravel are open source, so there is no per-seat license that grows with your headcount and no vendor whose pricing page decides your costs next year.

You also get documentation — what the system does, how it is deployed, and where the awkward parts are. That is what makes a handover to another developer a normal afternoon, not an archaeology project.

The fastest way to start is to send the file itself, or a version of it with the names changed. Ten minutes looking at a real spreadsheet says more than an hour of description, because the workarounds people have built into it are the requirements.