The process only exists in a spreadsheet
One file, three tabs, formulas someone built years ago and left. Half the team keeps a private copy, and the versions disagree.
INTERNAL TOOLS · DASHBOARDS · REPORTING
When the spreadsheet has become the whole system.
Build a clearer way to manage jobs, records and reporting. We develop internal tools around the work your business actually does, where an existing product cannot meet the need, with access, documentation and handover agreed from the start.
01 · What is actually breaking
The spreadsheet became the system. Nobody decided that.
Nobody quite believes the report
The figures arrive and the first question is whether they are right. Two systems count the same job differently, so the meeting starts by reconciling the two versions instead of deciding anything.
The software nearly fits
The package was bought for a business shaped slightly differently. People work around it: notes in the wrong field, an export into a spreadsheet, the same step done twice.
02 · What gets built
Tools for the job you actually do. Not the one the software company imagined.
01
Internal tools built to your process
A working application for the part of the business that off-the-shelf will not cover. Job tracking, case handling, quoting, scheduling, whatever the awkward middle of your operation actually is.
BUILT TO FIT 02A data model that holds up
We decide what a job, a client and a status actually mean before writing screens. Get that wrong and every report afterwards inherits the confusion.
ONE DEFINITION 03Reporting people will act on
Dashboards that show where each figure came from and when it last updated. If a number looks wrong you can click into the rows behind it and check.
SHOWS ITS WORKING 04Role-based access
Who sees what, who can change what and a record of who changed it. Branch managers, contractors and finance each get their own view, not the whole database.
RIGHT EYES ONLY 05Documentation and ongoing support
You get the source, the data dictionary and a written explanation of how it runs. We stay on for changes, but another developer could pick it up without ringing us.
NO BLACK BOX
03 · How we approach it
The smallest thing that fixes it. Then only what earns its place.
We treat a request for custom software as two or three separate problems wearing one name until it proves otherwise. We sit with the people doing the job, watch the workarounds and separate what genuinely needs building from what a configuration change or a tidier spreadsheet would fix. Sometimes the honest answer is that you do not need us to build anything.
Scope is written down as a list of records and screens, then cut into slices that each end with something running on your real data. You keep the code, the database and the hosting in your own accounts, so nothing is hostage to us staying. When something we built turns out to be wrong for how you work, we say so and change it rather than defending the original design.
04 · How it is delivered
Four steps, in this order. The order is the point.
Shadow the current process
Time on site with the people who do the work, including the spreadsheets they keep privately. We note every field they retype and every export they do by hand. The workarounds tell you more than any requirements document.
Agree the data model first
We write down what each record means, how it relates to the rest and which system owns it. You approve that before a single screen is designed.
Ship a narrow first version
One team, one workflow, real data, running for real. It exposes the wrong assumptions early, while changing them is cheap and nobody has been retrained yet.
Hand over properly, then support it
Written documentation, a walkthrough recorded for whoever joins later, admin accounts in your name and a named person here to call when something breaks.
05 · Questions worth asking first
Before you start. Practical questions, answered.
What to consider when deciding whether this work is right for your business.
Can one report pull job costs from SQL Server and invoice totals from Xero?
Yes, once both sides carry the same job reference. That reference is the join, and without it a report can only put two sets of numbers side by side and let a person squint at them. Agreeing where the reference gets entered is the work. The chart is the easy part. Joining two systems up
Our board pack is rebuilt by hand in Excel from a pile of exports. Can that stop?
Usually. The exports are replaced by a scheduled load into one table, and the pack reads from that table, so the same numbers appear whoever opens it and whenever they do. Rebuilding by hand ends because there is nothing left to rebuild, only a refresh that runs before the meeting.
Jobs raised in our own system sit unassigned because nothing chases them. Can the tool chase?
Yes. The chase comes from the record itself: anything sitting in the same state longer than the rule allows raises to a named person, and the raise is written on the job so the next person can see it happened. Nothing depends on somebody remembering to look.
Customers ring us for copies of their service certificate. Can they get it themselves?
Often yes. The certificate already exists as a file against the job, so a signed-in page lists the files belonging to that customer and generates nothing new. The work is deciding who may see which job, which is a permissions question rather than a document question, and it belongs to you. Customer self-service pages
We already pay for Power BI. Would you build reporting instead of using it?
No. Power BI does the visual side well, so use the product you already pay for and put the effort underneath it, into the table it reads from. Most reporting complaints turn out to be about numbers arriving late or coming from a source nobody in the room agrees with.
If we stop working with you, who owns the code and can anyone else maintain it?
The scope records ownership of custom work, your business accounts and data, and any third-party licences or managed services. We agree the access, documentation and export arrangements needed for handover before building, so you understand what can move and any dependencies that remain.
WORKING EXAMPLESWebsites built for businesses we own and run
WRITTEN SCOPEDeliverables and price agreed before work begins
DIRECT CONTACTA named person responsible for your project
CLEAR HANDOVERAccounts, access, documentation and support agreed up front
06 · Where this applies
Where a spreadsheet gives out first. Regulated and full of exceptions.
Regulated work, awkward exceptions and a duty to show who saw what. Once records have to be defensible as well as accurate, a shared file stops being a safe place to keep them.
FOR INSURANCE BROKERS AND MGAS
Less rekeying
Explore document handling, enquiry workflows and connections between policy, CRM and finance systems.
EXPLORE → FOR SOLICITORS AND LAW FIRMSGive your people more time
Reduce repeated requests, scattered updates and manual copying between systems.
EXPLORE → FOR PRIVATE HEALTHCARE AND CARE PROVIDERSMake the admin easier
Clearer websites and booking journeys help people find the right service.
EXPLORE →The test of an internal system is not the demo. It is whether whoever inherits it can still follow the data model without us.
NEXT · Tell us what you want to improve
Start with the change you want to make.
Describe the work your current tools cannot handle. We will help define a useful first version and the information needed to quote it.