The fastest way to tell whether a small business has outgrown its software is to ask one question: “How long does it take you to answer a question you have not asked before?” If the answer involves exporting a CSV, opening Excel, copy-pasting from a second tool, and then walking the result over to the accountant, your reporting is broken. It does not matter how clean the dashboards look in the marketing screenshots of whatever software you are paying for. The minute you need something the vendor did not anticipate, you are doing the work yourself.
This post is about the bit of custom software that most owners do not think to ask for and that, once they have it, they never give up: a proper custom reporting layer. A small database that knows where your business data lives, joins it together, and produces the handful of numbers your business actually runs on. Sometimes called a custom reporting tool, sometimes a custom dashboard, sometimes just “the report Steve in finance keeps asking for”. Same thing.
Why off-the-shelf reporting fails most small businesses
Every modern SaaS tool ships with a “Reports” tab. Xero has one. HubSpot has one. Your booking system has one. They all look fine until you try to answer a real question.
The problem is structural, not cosmetic. Each tool only knows about its own data. Your accounting platform does not know which job a payment relates to. Your CRM does not know which invoice has been paid. Your job management software does not know your true gross margin because the cost lines live in three other places. Each tool gives you a partial truth. When you stitch them together by hand, you get a fragile, slow, error-prone version of the answer.
A custom reporting layer fixes this by pulling data from every tool into one place, joining it correctly, and presenting it as the report you actually need. Business intelligence ↗ is the formal term for this kind of work. For most small businesses, “BI” sounds like overkill. It is not. It is the same idea, sized for a five-person team rather than a 500-person finance department.
The four questions that expose broken reporting
Run these past your current setup. If any of them takes more than ten minutes to answer, your reporting is the bottleneck, not your data.
1. What is our real gross margin by customer for the last 90 days?
Revenue lives in one system. Cost of delivery lives in another. Time, if you track it, lives in a third. The honest answer requires joining all three at customer level. Almost no off-the-shelf reporting tool can do this without manual reconciliation.
2. Which customers have slipped from paying in 30 days to paying in 60?
This is a comparison across two time windows of the same metric, segmented by customer. Most accounting systems will show you ageing today, but not the trend. To see the trend you need historical snapshots, which means you need a small database that captures the state of your invoices on a schedule.
3. How much did we spend on tools we are not using?
SaaS creep is real. A custom report that pulls licence counts from each platform, joins them to actual user activity, and flags inactive seats can save more in subscription costs every quarter than the report costs to build.
4. What is the lead time from quote to cash for jobs over £5,000?
Quote date is in the CRM. Acceptance date is in the booking or job system. Invoice date is in the accounting system. Payment date is in the bank feed. Four systems, one metric. This is the kind of question that quietly drives every decision about hiring, pricing, and cash flow, and yet most small businesses have no way of answering it consistently.
What “custom database reports” actually look like
A useful mental model. A custom reporting layer is normally three things, not one.
| Layer | What it does | Typical tech |
|---|---|---|
| Data warehouse | A small database that holds clean copies of your business data from every source | Postgres, BigQuery, or a managed equivalent |
| Pipeline | Scheduled jobs that pull data from each tool’s API and write it into the warehouse | Custom scripts, n8n, or an off-the-shelf ETL tool |
| Reports | The actual dashboards and tables that humans look at | Looker Studio, Metabase, or a custom front end |
The data warehouse is usually a Postgres database. The pipeline is whatever combination of API calls and ETL ↗ jobs gets data in on a schedule. The reports are typically built in Looker Studio ↗, Power BI ↗, an open-source tool like Metabase, or a small custom dashboard if the team only needs three or four views.
This is not a “rebuild everything” project. You keep the systems you have. You add a thin, well-defined layer that turns them into one coherent single source of truth ↗ for reporting.
A worked example: a 12-person services business
A typical setup I have built more than once.
The business runs on Xero for accounting, HubSpot for sales, a custom job management tool, and a shared Google Drive for everything else. Five people had a question they could not answer without help, every week. Reporting was the single biggest source of “can you send me a CSV” emails on a Friday afternoon.
What we built:
- A small Postgres database hosted on a £20 a month managed service.
- Three nightly pipelines pulling from Xero, HubSpot, and the job tool’s database, writing into clean tables in Postgres.
- A Metabase instance with eight dashboards covering revenue by customer, margin by job, sales pipeline by stage, ageing by customer, time-to-cash by job, SaaS licence usage, support volume by client, and a monthly board summary.
- Read-only access for the leadership team. Editable access for one analyst.
Time to build: 5 weeks of part-time work, mostly the pipelines. Cost to build: in the region of £8,000 to £12,000 for a service like this delivered by a small team. Ongoing cost: about £40 a month in hosting, plus a managed software fee that covers updates and changes when the underlying tools’ APIs change.
The single biggest impact was not the headline numbers. It was that nobody had to ask for a report any more. The Friday afternoon “can you send me a CSV” emails stopped within a fortnight.
How long this takes, and how much it costs
Honest ranges for a small business with three to six source systems and a handful of reports.
Two things to flag. First, these are build costs, not run costs. Ongoing hosting for a small Postgres database and a reporting tool sits in the £30 to £150 a month range for most setups. Second, anyone quoting you above this range for a small business reporting project is either solving a much larger problem (proper data warehousing, machine learning, multi-entity consolidation) or quoting enterprise rates for a job that does not need them.
The four mistakes that waste reporting budgets
I have seen every one of these more than once. They are all avoidable.
Mistake 1: Building dashboards before agreeing the questions
People want to see the dashboard. So they ask for it. The dashboard gets built, demoed, admired, and then ignored, because nobody actually asked the question it answers. Start with the question. Write it down. Agree what “good” looks like. Then build the report.
Mistake 2: Trying to live without a database
Tools like Zapier and Google Sheets are fine for moving data, but they are not a place to store it. The minute you want history, you need a database. Skipping the database to save £20 a month is the most common false economy in this whole space.
Mistake 3: Underestimating API rate limits
Some platforms (HubSpot’s free tier is a famous one) have aggressive rate limits on their API. Your pipeline has to respect them, or the data will go stale at the worst possible moment. This is the single most common cause of “the report is broken again” two months after launch.
Mistake 4: Treating reporting as a one-off project
Your tools’ APIs change. Your business questions change. The exec who wants “revenue by region” this quarter will want “margin by product line” next quarter. A reporting layer is a living thing. Build it with someone who will be around to maintain it, or budget for that maintenance from day one. This is the heart of what managed software actually means.
Data protection: what to do before you copy data around
Pulling business data into a central database is, technically, processing personal data, and it falls under UK data protection law ↗. For a small business the practical checklist is short but non-negotiable.
- Document what data you are moving and why. The ICO’s UK GDPR guidance ↗ is the canonical reference.
- Host the database in the UK or EU unless you have a specific reason not to.
- Restrict access. Read-only by default. Named users, not shared logins.
- Back up the database. Test the restore at least once.
- Use a sensible security baseline. The NCSC’s Small Business Guide ↗ covers the essentials.
This is not theatre. If a customer requests deletion under GDPR and you have copied their data into a reporting database, that database is in scope too. Plan for it.
How a custom reporting layer interacts with the rest of your stack
A common question: “Will I still need my CRM/accounting/job tool?” Yes. The reporting layer reads from them. It does not replace them. You keep your tools as the systems of record. The reporting layer is the layer above, that turns three or four partial truths into one coherent view.
If you have been reading along and thinking that this sounds a lot like the operational layer described in signs your business has outgrown Sage 50 or signs your business has outgrown its software, you are right. Reporting is often the first piece of that operational layer, because it is the cheapest to build, the easiest to demonstrate value with, and the one that creates the appetite for the rest.
A three-step way to start without committing to a big project
If you are not ready to commission a full reporting layer, here is a sensible warm-up that costs almost nothing and takes a fortnight.
Step 1: Pick three questions. Not ten. Three. Write them down. Phrase each one as a single sentence ending with a number or a percentage. “What is our gross margin on top-five customers this quarter, expressed as a percentage.”
Step 2: Time how long it takes to answer them today. Honestly. Include the back-and-forth with whoever you have to ask. This is your baseline cost.
Step 3: Specify what an automated version would look like. One page. What data goes in, what the report shows, how often it refreshes, who sees it. That one page becomes the brief. If you want help turning that into a working build, how to write a brief for custom software walks through the next layer of detail.
That single one-page document is, in my experience, the difference between a reporting project that pays for itself within a quarter and one that drifts.
Frequently asked questions
Is this the same as a “data warehouse”?
Functionally, yes, just sized for a small business. A data warehouse is just a database designed for reporting rather than operational use. For a 5 to 50 person business it is usually a single managed Postgres database. Big enterprises have multi-tier warehouses with staging, marts, and cubes. You do not.
Can I just use Looker Studio (or Power BI) directly against my accounting system?
Sometimes, for very simple reports. The problem is that most business questions need data from more than one system, and most off-the-shelf connectors do not join cleanly. A small intermediate database makes the joins trivial. Without it, you are doing the joins in the BI tool, which is fragile and slow.
How do I know if my tools have an API I can pull from?
Almost every modern SaaS tool has an API. Xero, HubSpot, Pipedrive, Monday, Jira, Stripe, GoCardless, Mailchimp, Calendly, all of them. The exceptions are usually older desktop tools (some older Sage 50 installs, for example) which need an extra step. If you are not sure, list your tools and ask. It takes ten minutes to check.
Will this work if my data is currently in spreadsheets?
Yes, but the spreadsheets become the constraint. The reporting layer can absolutely read from Google Sheets or a SharePoint Excel file. The challenge is data quality. Spreadsheets are flexible, which means humans have usually been creative with them in ways that break automated reading. We covered this in from spreadsheet to software. If your spreadsheets are tidy, this is easy. If they are not, expect to spend time cleaning them up first.
How is this different from an “AI dashboard”?
An AI dashboard usually means a chat interface that lets you ask questions in natural language. That is a thin layer on top of a proper reporting setup. You still need the underlying database and pipelines for it to work. Without them, the AI is just guessing, or hallucinating, or rephrasing whatever single source it has access to. Start with the reporting layer. The AI front end is a small addition on top, once the data is in shape.
Do I need an in-house analyst to run this?
For a small business, no. Once the pipelines and dashboards are built and managed, a non-technical user can read them, change date ranges, and export to Excel. New reports do require someone to write the query, and that is usually the managed software provider’s job.
Worth a conversation?
If you are reading this and thinking “yes, we waste hours every week on reporting”, the cost of fixing it is almost always lower than the cost of carrying on. Most of the small businesses I work with are surprised by how small the build actually is once it is properly scoped.
If you want to talk through what your reporting layer could look like, what it would cost, and how quickly it would pay back, get in touch. Bring your three questions.