Data engineering & analytics
Pipelines, warehousing and reporting built so that two people asking the same question get the same answer — and so that broken data is caught by a test rather than by an executive.
When every department has its own numbers
The familiar symptom is a meeting where sales and finance present different revenue figures and the discussion becomes about whose spreadsheet is right rather than what to do. Both are usually defensible; they defined the metric differently, and neither definition is written down anywhere.
Underneath sits a second problem. Reports built directly on top of operational databases break whenever an application changes, and nothing tests whether the numbers are still correct — so errors are discovered by whoever spots something implausible, often weeks later.
Fixing it is less about tooling than about agreement: one definition per metric, held in version control, transformed in one place, and tested on every run.
What we build
Ingestion pipelines
Scheduled and event-driven loading from your applications, third-party APIs and files, with schema handling that fails loudly instead of silently dropping fields.
Warehouse modelling
A modelled layer between raw data and reports, so definitions live in one reviewable place rather than being re-implemented in each dashboard.
Data quality tests
Assertions on freshness, uniqueness, referential integrity and expected ranges, run on every pipeline. You hear about a problem from an alert, not a director.
Reporting and dashboards
Built on the modelled layer so numbers reconcile, and fast enough that people actually open them.
Operational analytics
Metrics fed back into the systems where work happens, rather than sitting in a dashboard nobody has time to check.
Documentation and lineage
What each metric means, where it comes from and what breaks if it changes. The thing that makes a data platform survivable when someone leaves.
Typical stack
Chosen per project, not by habit. If your team already runs something that works, we use it.
- Warehouse
- PostgreSQL
- BigQuery
- Snowflake
- DuckDB for smaller volumes
- Pipelines
- dbt
- Airflow
- Dagster
- custom Python where it is simpler
- Reporting
- Metabase
- Looker Studio
- Power BI
- custom dashboards
- Quality
- dbt tests
- Great Expectations
- freshness monitoring
- anomaly alerting
How a data project runs
We start from the decisions you want to make, not the data you happen to have. A warehouse built without that anchor becomes an expensive copy of your production database that nobody queries.
- 01
Define the questions
The decisions this should support and the metrics behind them, with definitions agreed in writing across the departments that disagree today.
- 02
Build the spine
Ingestion and modelling for the highest-value questions first, with tests from the beginning.
- 03
Report
Dashboards on the modelled layer, plus training so people can answer their own follow-up questions.
- 04
Extend
Further sources and metrics added onto a foundation that already works, rather than a second parallel system.
Common questions
Do we need a data warehouse, or will a dashboard tool do?
If you have one main system and simple reporting needs, connect a dashboard tool to a read replica and stop there. A warehouse earns its cost when you are joining several sources, when history matters, or when reports are slowing your production database down.
Why do our reports disagree with each other?
Almost always because the same metric is defined differently in each one — a different date field, a different treatment of refunds, a different exclusion. The fix is one modelled definition in version control that every report reads from.
Can you work with our existing BI tool?
Yes. The modelling layer is what matters and it is tool-agnostic; we build against whatever you already have licences and skills for rather than starting a migration you did not ask for.
How do we know the numbers are right?
Automated tests on every run — freshness, uniqueness, referential integrity, expected ranges — with alerts on failure. Plus a reconciliation against source systems for the metrics that matter most.
What about personal data and GDPR?
Personal data is minimised, pseudonymised where analysis allows, and given retention rules enforced by the pipeline rather than by policy alone. Residency requirements are settled before anything is built.
Start with a scoping call.
Thirty minutes, no obligation. If we are not the right fit we will tell you on the call rather than after a proposal.
Related services
Cloud & DevOps
Migration without a big-bang cutover, infrastructure defined in code so environments are reproducible, and pip…
API development & integrations
Connecting systems that were never designed to talk to each other — including the awkward ones with a SOAP end…
LLM & RAG integration
Getting a model to answer questions about your own content is easy to prototype and hard to trust. The differe…