What We Do
Analytics engineering and the data platform underneath it.
Data work, done properly
We build dbt projects and the AWS data platforms they run on. Staging, intermediate and mart layers with tests and CI that fail loudly, ingestion and warehouse architecture that survives a new source system, and reverse ETL that pushes modelled data back into the tools your team works in. Every engagement is delivered by a principal engineer.
Modular SQL transformations organised into staging, intermediate and mart layers, with tests and documentation generated from the project itself. Most dbt projects start clean and stop being clean somewhere around model number eighty.
Have a dbt project that needs a second pair of eyes?
Ingestion, storage, transformation and consumption designed as independently evolvable layers rather than one tightly coupled pipeline. The real test of a platform is whether it still makes sense eighteen months later.
Building a platform, or rebuilding one that outgrew its design?
Modelled data pushed back into the tools your team actually works in, built on the same tested dbt models that power your reporting, so the CRM and the dashboard agree on the number.
Data sitting in the warehouse and nowhere else?
Tests at ingestion and at each transformation, alerting routed to whoever can act on it, and runbooks for the failure modes found during implementation. A pipeline that fails silently is worse than one that fails loudly.
Not sure whether your numbers are right?
Which of these is your problem?
Four services, one discipline. A side by side look at what each one covers, so you can see where your project fits before you get in touch.
| Category | dbt Model Development | Data Platform Architecture | Reverse ETL Pipelines | Data Quality & Observability |
|---|---|---|---|---|
| Focus | Modular SQL transformations organised into staging, intermediate and mart layers, with tests and documentation generated from the project itself. | Ingestion, storage, transformation and consumption designed as independently evolvable layers rather than one tightly coupled pipeline. | Modelled data pushed back into the tools your team actually works in, built on the same tested dbt models that power your reporting, so the CRM and the dashboard agree on the number. | Tests at ingestion and at each transformation, alerting routed to whoever can act on it, and runbooks for the failure modes found during implementation. |
| What's included |
|
|
|
|
| Explore | Learn More | Learn More | Learn More | Learn More |
How Engagements Work
Two ways in, both priced before work starts
Scope is agreed in writing before anything begins. There is no discovery phase you pay for twice, and no day-rate meter running while scope drifts.
| Scope | Terms |
|---|---|
| Fixed price dbt pipeline audit | EUR 2,500. Five business days. 30% deposit before work starts. You get the top ten issues ranked by risk, two to three models refactored as a working example, and a written report your team can act on without us in the room. |
| Project work | Scoped and priced in writing. 30% deposit before work starts, on every contract regardless of size. The balance is invoiced against agreed milestones rather than at a single handover. |
| Day rate and ongoing engagements | Quoted against scope after a first call. |
Send us the shape of your problem and you will get a number for your scope.
Every model ships with a primary-key test and a not-null test at minimum. Every project gets documentation generated from the project itself, so it cannot go stale the way a hand-written wiki does, and a CI pipeline that runs dbt build on each pull request. This is not a stylistic preference. It is what stops a broken model from quietly reaching a dashboard.
How We Work
One discipline
Analytics engineering and the data platform under it, delivered to one standard on every engagement.
Layered by default
Staging models map one to one with sources. Intermediate models hold the joins and business logic. Marts are what your dashboards read. Every model lives in exactly one of the three.
Tests before features
Tests, documentation and CI are part of the first model, not a cleanup phase that never gets scheduled. Failures should be loud and early.
Stated limits
We publish what we do not take on. The list is on the dbt page, because a gap found halfway through a project costs far more than reading it here.