When a team has outgrown its spreadsheets but nothing on the market fits the way it actually works, a small internal tool is often the sensible middle ground: one place where work is logged once, checked as it goes in, and shown to each person in the form they need. I scope and build small internal tools and operational dashboards for UK teams, keep them simple enough to hand over, and document them so you are not reliant on me to keep them running.
What changes when the spreadsheet becomes a tool
The warning signs are familiar. A shared workbook with twenty tabs, a colour code only one person understands, a “master” copy alongside two others called “final”, and a morning routine of copying rows from one tab to another. A formula breaks when someone sorts a column, and nobody can say who changed a figure or when.
An internal tool moves the records into a proper database and puts a simple form in front of it, so each entry is made once and validated on the way in. Each person then gets the view they need. The operations lead sees what is overdue, a director sees the weekly position on a dashboard, and an engineer out on site sees only today’s jobs on a phone. The spreadsheet stops being the system and becomes, at most, an export.
Who it suits, and who it does not
It tends to suit small UK teams where:
- one or two spreadsheets have quietly become the working record for jobs, orders, stock, bookings or cases;
- the same details are typed into more than one place, and the copies drift apart;
- the software built for your sector does far more than you need, charges per user at a rate that makes no sense for your size, or forces a process you do not follow;
- someone senior spends hours each week assembling figures that already exist somewhere in the business.
It is not always the right answer. If an established product already fits your process at a fair price, buy it. Bought software comes with support, updates and security fixes that a small custom build has to arrange for itself, and I would rather tell you that on the first call than build something you did not need. Equally, if what you need is a public website rather than a tool for your own staff, that is a different job, closer to a website redesign.
What I build
Operational dashboards
A live view of how the business is running, drawn from its own records: jobs in progress, orders waiting to be dispatched, cases past their deadline, invoices unpaid after 30 days. The point is to answer the questions a manager asks every morning without anyone compiling a report. If what you want is marketing reporting, such as ad spend and website traffic in one place, a reporting tool like Looker Studio is usually the better fit, and that is a separate piece of work.
Data-entry apps and trackers
Forms and lists over a shared set of records: a job tracker, a stock register, a supplier log, a complaints log. Drop-down choices replace free text, required fields cannot be skipped, and each record shows who created it and who last changed it.
Approval and hand-off screens
For work that passes between people: a request is raised, a manager approves it, and someone else picks it up. Each step is recorded with a name and a time, so nobody has to ask where something has got to.
What I deliberately do not build
- public, customer-facing apps, or anything that takes card payments;
- the sole legal record for regulated work, such as clinical notes or client money accounts;
- replacements for accounting, payroll or HR software, which are mature products worth paying for;
- anything that needs someone on call around the clock.
A small business should not depend on one consultant for something its safety, legal compliance or ability to pay people relies on. Those systems need a supplier with support behind them.
How a build runs
- Walk-through. You show me the spreadsheets and talk me through a normal week: who enters what, who needs to see what, and where things go wrong.
- Written scope. The screens, the fields, the users and what each of them may see, what is left out, which platform I recommend and what it will cost to run. Nothing is built until you have agreed it.
- Data clean-up. Existing records are tidied, duplicates merged and inconsistent entries standardised before they are imported. This step usually takes longer than people expect, and skipping it carries the old problems straight into the new tool.
- Build in stages. The first usable screen comes early, normally the one that replaces the most painful tab, and the people who will use it test it with real work.
- Running side by side. The old spreadsheet and the new tool run in parallel for a short period until the team trusts the new one.
- Handover. Documentation, training for whoever will administer it, and every login and subscription confirmed as yours.
I choose the platform after the scope is agreed, not before. For many small teams a low-code platform, where screens are assembled rather than written line by line, is quicker to build and cheaper to change later; for others a small custom web app is the better fit.
Problems I see most often
- No single owner of the data. Two people keep their own versions, and month-end becomes an argument about which is right.
- Free text where there should be a list. “Kensington”, “kensington ” and “W8” all mean the same place, so every count by area is wrong.
- Personal data visible to everyone and kept indefinitely. Customer names, addresses and phone numbers sit in a file the whole company can open. Under UK GDPR you should hold only what you need and limit who sees it, and a new tool is a good moment to apply data minimisation properly.
- Shared logins. One username for the whole office means there is no record of who did what, and no way to remove a leaver’s access without changing it for everyone.
- Everything in one person’s head. A tool built around one colleague’s habits stops making sense the week they leave.
What you receive
- The working tool, set up in accounts your business owns, with your own administrator login.
- Individual user accounts with permissions matched to each role.
- A short guide for the people who use it and a technical note for whoever maintains it.
- A plain record of what personal data the tool holds, who can see it and how long it is kept, which helps with your own UK GDPR records. Where a platform stores that data for you, it acts as a processor, so I check its terms and where it hosts data; the difference between a data controller and a processor matters here.
- Any custom code kept under version control in a repository you own.
Any support after handover, and its terms, is agreed in writing before the build starts, so you know from the outset who looks after the tool once it is live.
What it costs to build and to run
The build cost depends on the number of screens, the number of user roles, how many outside systems it connects to and how tidy the existing data is. Each quote is written after a free first call, in GBP, and agreed in writing before work starts.
The running cost matters just as much. Low-code platforms are usually charged per user per month, and custom apps need hosting and occasional updates. I set out both in the scope, so you can compare the total over two or three years against an off-the-shelf product before you commit.
Next step
Send me screenshots of the spreadsheet that causes the most trouble, with any personal details blanked out, and a few lines on who uses it and what goes wrong. I will tell you honestly whether I think the answer is a custom tool, a product you can buy, or simply a better-organised spreadsheet. You can do that, or book a free 30-minute call, through my contact page.