Services
We build the pipelines, warehouses and reporting layers that turn operational databases into numbers people trust enough to make decisions with, and we migrate organisations off legacy databases that have outgrown their original design without losing the history buried in them.
The measure of this work is not that a dashboard loads. It is that when the finance director asks why last month's figure changed, someone can trace it to the exact source rows and transformation that changed it, in minutes rather than days.
When you need this
What we build
Our approach
A dimensional model — facts, dimensions, grain agreed explicitly — is designed against how the business actually asks questions, before a single pipeline is built. Skipping this step is the single most common cause of a warehouse that technically works but that nobody can query without help.
Every load includes checks against the source: row counts, checksums on key fields, and business-rule assertions specific to your data. A load that fails these checks stops before it reaches the reporting layer and pages the owner, rather than quietly publishing numbers that are wrong.
Not every changing attribute needs full history — correcting a typo in a customer name is a type 1 overwrite, but a change of sales region or price tier that affects historical reporting needs type 2 versioning with effective dates. We go through each dimension attribute and agree the rule with the people who use the reports.
Legacy migrations run both systems side by side for an agreed period, with automated reconciliation comparing outputs daily. Discrepancies are investigated and resolved before the legacy system is switched off, and anything that genuinely does not map to the new schema is documented and flagged rather than quietly dropped.
We generate lineage from the pipeline code itself (via dbt's dependency graph and column-level lineage tooling) so it stays accurate as pipelines change, rather than maintaining a separate document that is out of date within a month.
Technology
Warehousing
Transformation and orchestration
Ingestion and CDC
Quality and lineage
Applied by industry
Activity and outcomes reporting warehouses drawing from EMIS Web, SystmOne and Dentally extracts, with strict field-level access control and reconciliation against commissioner-facing reports.
Settlement and consumption data pipelines from Elexon and supplier feeds into a warehouse, with slowly changing dimensions for tariff and portfolio structure so historical billing reports stay correct.
Multi-site sales, stock and labour data consolidated from EPOS and rota systems into one reconciled daily reporting layer, replacing per-site exports that disagree.
Migration from legacy lettings databases into a modelled warehouse, with type 2 history on tenancy and rent changes so historical arrears reporting remains accurate after migration.
Time, billing and matter data consolidated from practice management and finance systems into a reporting layer that partners can query directly, with lineage back to the source ledger entries.
Typical engagement
Questions
With the mismatch, not the technology. We trace one disputed figure back through every transformation to its source rows, which almost always surfaces the actual fault: a silent join fan-out, a currency or timezone conversion applied twice, or a slowly changing dimension overwriting history instead of versioning it. Fixing that one figure properly, and adding the test that would have caught it, does more for trust than any dashboard redesign.
A field-by-field mapping from the old schema to the new one, including the undocumented meanings — the status code that means one thing in the UI and another in three legacy reports. We run the migration with reconciliation: row counts and checksums compared between old and new for a defined parallel-running period, not a single cutover weekend and hope. Historical data that doesn't fit the new model cleanly is flagged explicitly rather than silently dropped or force-fitted.
CDC streams row-level changes out of a source database (via write-ahead log readers such as Debezium) as they happen, instead of running a nightly batch extract that misses intra-day changes and puts load on the source system at 2am. It's worth the operational complexity when downstream systems need near-real-time data or when nightly batch windows no longer fit the data volume; for a once-daily reporting refresh with modest volume, a well-indexed batch extract is simpler and cheaper to run.
As a slowly changing dimension, type 2: each change creates a new row with effective-from and effective-to dates, so a report for March correctly uses the address that was current in March, not today's. This matters most in regulated reporting and commission calculations, where using the current value for historical periods produces numbers that are simply wrong, not just imprecise.
Automated data quality tests run on every load: row counts within expected bounds, referential integrity, null and duplicate checks on key fields, and business-rule assertions (a percentage that must sum to 100, a total that must reconcile to a source system). Failures block the pipeline and alert an owner rather than publishing a broken table quietly, and lineage is tracked so anyone can trace a report figure back to its source tables and transformations.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us