Numbers the whole company agrees on.
A place the reporting reads from, every metric defined once, and dashboards built around the decision somebody makes weekly rather than around whichever columns happened to exist.
- 3 – 6 weeks
- scope to live
- Fixed price
- against a written scope
- Your accounts
- no proprietary layer
Who this is for
You probably need this if…
01
Every question becomes a ticket
Somebody wants a number, an engineer writes a query, and three days later the meeting it was for has already happened without it.
02
Two dashboards disagree
Both are technically correct, because the same word was defined differently in each, and the result is that nobody trusts either one.
03
Reporting slows the product down
Month-end queries run against the same tables serving customers, and everybody can tell when finance is closing the books.
What we build
The work, in detail.
Warehouse & modelling
A single place reporting reads from, modelled for the questions you will ask in two years rather than only the chart needed this week.
Metrics layer
Every definition written once, versioned in the repository and reviewed like code. “Active customer” stops meaning three different things.
Dashboards
Built around a weekly decision, not around every available column. Fewer views, actually opened, rather than forty nobody reads.
Self-serve analytics
Documented models in plain SQL so a non-engineer can answer their own question without raising a ticket and waiting two days.
Quality checks
Freshness, row-count and null assertions in the pipeline. Data that fails stops rather than flowing through and quietly getting charted.
Experimentation
A/B infrastructure with the sample size agreed beforehand, so a result is a conclusion rather than encouragement.
Executive reporting
The four numbers that actually run the business, on a schedule, each with a sentence on why it moved.
Multi-system joins
Product, billing, support and finance brought together, including the hard part: agreeing what a customer is across all four.
Practice areas
The disciplines behind it.
You buy this as one engagement at one price. Underneath, it draws on 3 of our practice areas, and the same people cover all of them.
Analytics & Insight
Turning what the business already records into something it can decide with.
- Data warehousing
- Metrics layer
- Dashboards
- Self-serve analytics
Data & Sync
Getting the same number in two places, and keeping it there.
- Schema & modelling
- Delta sync
- Reconciliation
- Migration & backfill
AI & Automation
AI applied where it removes real work, not where it reads well in a deck.
- Grounded assistants
- Document extraction
- Workflow automation
- Semantic search
How it runs
Four weeks, in order.
Week 1
Define
Which decisions need which numbers, and what each metric actually means. This is the week that prevents two dashboards from disagreeing later.
Week 2
Model
Extraction, the warehouse or read model, and the metric definitions in version control. Friday demo on your real data.
Week 3
Surface
Dashboards, self-serve models and the quality assertions that guard them. Second Friday demo with your team driving.
Week 4
Hand over
Documentation, a walkthrough with whoever will own it, and scheduled delivery of the executive report.
What you get, concretely
- A warehouse or read model, separated from production tables
- Metric definitions in version control, reviewed like code
- Dashboards for the decisions you named in week one
- Data quality checks that fail loudly in the pipeline
- Documented models a non-engineer can query
- Everything in your own accounts and repository
- 30 days of post-launch fixes at no additional cost
Typical engagement
Fixed price · three to six weeks
Driven mostly by how many source systems are involved and how much they disagree about what a customer is. Extraction is the easy part; reconciling definitions is where the time goes, and week one tells you how much there is.
Technology
What we build it with.
Defaults, not requirements. If you already run something else and have a team who knows it, we work in yours.
- Warehouse
- PostgreSQL, BigQuery, DuckDB
- Modelling
- dbt, SQL, versioned definitions
- Visualisation
- Metabase, Looker Studio, embedded charts
- Quality
- Freshness and volume tests, failure alerting
Proof
We have built this before.
Not a reference we cannot name. Systems we designed, shipped and still operate, with the decisions written down.
Questions
What people ask before signing.
- Do we need a warehouse, or is our database enough?
- At most sizes the database plus a read replica is enough, and we will say so rather than sell you infrastructure. A warehouse earns its place when you are joining several systems, not before.
- Who maintains it after you leave?
- You can, and it is built for that: documented models, plain SQL, no proprietary layer in the middle. If you would rather we kept it current, that sits in a support retainer.
- How do you handle sensitive data?
- Masked or aggregated at the model layer with access by role, so analysts see what the question needs and not a row more.
- Can you work with the BI tool we already pay for?
- Yes, and we would prefer to. Most teams already own more capability than they use, and a new tool rarely fixes what is actually a definitions problem.
- What if our data is a mess?
- That is the normal starting point. Week one reports honestly on what state it is in, including where the answer is that a source system needs fixing before reporting on it means anything.
- Will reporting slow down our app?
- No, because it never queries the tables serving customers. That separation is the first thing built, not an optimisation added later.
Related reading
Written on this, by us.
Data & Integration · 7 min read
The Data Migration Is the Project
Replacing a system is mostly moving its data, and that part is a business decision rather than a technical one. Why migrations overrun, and how to scope one honestly.
Data & Integration · 7 min read
The Same Number in Two Places
Your POS says one thing and your accounting package says another. Reconciling them is somebody's entire Monday. Here is why systems drift apart, and the boring job that keeps them together.
Data & Integration · 6 min read
Every Metric Means Three Things, and That Is Why Your Dashboards Disagree
Two reports, two answers, both technically correct. The problem is almost never the data. It is that nobody wrote down what the words mean.
Tell us which number nobody trusts.
Name the report that starts arguments. We'll tell you whether that is a data problem or a definitions problem, because they are fixed very differently.
Phone
+1 (407) 796-2376Reply time
One business day, from an engineer
Based in
Orlando, Florida · serving the United States
What happens next
- A reply within one business day, from an engineer
- A thirty-minute call, with no qualifying call before it
- A written scope and a fixed number, if it fits