Fast track to dbt.
Project structure, model layering, SQL style, testing, CI/CD, documentation. The conventions that decide whether a dbt project stays navigable at model number 800, made once across dozens of rollouts so you don't make them again.
Sound familiar?
The things we hear from teams already running dbt, or considering it.
The opinions, written down.
Six of the patterns we apply on every dbt project. Written down so you can read them before talking to us.
Layer by purpose. Bronze, silver, ADS, gold.
Staging models named stg_<source>_<entity>, one per source table, cast and rename only. Intermediate by business domain, not team. ADS as the harmonised contract for cross-source entities. Gold thin, business-ready, consumer-friendly names. Selection commands like dbt build --select intermediate.finance+ become trivial.
Defaults in dbt_project.yml. Not in every model.
Materialisations, incremental strategies, quoting rules set at project and folder level. Ad-hoc {{ config() }} overrides scattered through files make behaviour impossible to reason about. Path-level settings let reviewers understand a model's behaviour from where it lives.
Config first, single final CTE, no SELECT *.
{{ config() }} at the top, then CTEs in a clear progression (sources, transformations, final projection), ending in a single final CTE that returns the model. Explicit columns, lowercase snake_case aliases, uppercase keywords. Diffs stay predictable, lineage audits stay tractable.
Saturate sources and gold. Light on intermediate.
not_null and unique on every staging model and every gold fact or dimension. Relationship tests and contracts where downstream metrics depend on them. Intermediate models that stay ephemeral don't need dedicated tests; upstream staging and downstream gold cover them.
dbt build, not dbt run plus dbt test.
One command that materialises and tests together, so a broken model never reaches a downstream dependency. CI fails fast on test failures, freshness blocks with warn/error thresholds (warn after 18h, error after 26h) on critical sources. No green build, no deploy.
Docs live next to models. Or they don't live.
_models.yml and _sources.yml colocated with the models they describe. doc() references for canonical text, owners declared on every model, exposures wired to Power BI reports and notebooks. CI fails on undocumented models. Separate doc files always drift.
How we deliver a dbt project
Four steps. The same every time. The decisions inside each one come from doing it dozens of times, not from reading a docs page.
Anchor
One source, one mart, one stakeholder who cares. We ship one usable model end-to-end before we touch the rest of the project. Naming, layering, and tests get set with that first model.
Layer it right
Staging per source, intermediate by domain, ADS as the integration contract, gold thin and consumer-friendly. dbt_project.yml carries the defaults so every new model inherits the patterns automatically.
Build with conviction
Tests saturated on sources and gold, docs co-located with models, dbt build wired into CI, freshness on the sources that matter, dbt Power User as the standard IDE setup, SQLFluff in pre-commit. The opinions are already made.
Hand it over
Scheduled builds, ownership on every model, exposures pointing at the dashboards that consume them. Your team adds the next mart without us, and the project stays navigable at model number 800.
Skip the eighty decisions every dbt project re-litigates.
For dbt you don't need a wizard. You need someone else's opinions on the decisions every project re-makes from scratch. Lift what works, fork the rest, or have us implement it for you.
- Layered project structure (staging, intermediate, ADS, gold) with naming rules
- SQL style guide and the patterns that go in dbt_project.yml
- Testing strategy: where to saturate, where to stay light
- CI gates, freshness thresholds, ownership and exposure conventions
Pairs well with
dbt is the transformation layer. The platform underneath is a separate decision, and we have an opinion on both.
FAST TRACK →dbt on Databricks
Databricks SQL Warehouses as the dbt adapter, Unity Catalog as the governance layer, Asset Bundles to ship the project. We bring the same opinions to the platform layer.
FAST TRACK →dbt on Fabric
Native dbt jobs are now in Fabric. We use it for teams that already standardised on Fabric capacity and want SQL-first transformations on top of the lakehouse.
dbt work sits inside Analytics, part of Build.
Strategy decides if dbt is the right pick for the transformation layer. We build it. Experts keep it running once we hand it over.
Strategy
From business questions to a data, AI and software direction your organisation can follow.
Explore →Build
Data and analytics, AI, and custom software. Built with adoption and ownership from day one.
Explore →Experts
Specialists who think like teammates. Keep your engine running and your team growing.
Explore →Thinking about dbt? Talk to us first.
Half-hour call. We'll tell you if it's the right pick for your situation, and how to set up a project that stays navigable as it grows.
Book a dbt chat