dbt Consulting

We build and clean up dbt projects on Snowflake: models your reports can trust, tests that catch a bad load before anyone sees it, and documentation your team can maintain without us.

Where the numbers come from
  1. 1

    Raw source tables

    Loaded as-is from each system, never edited by hand

  2. 2

    Staging models

    One per source table: renamed, typed and deduplicated

  3. 3

    Intermediate models

    Joins and business rules, written once

  4. 4

    Reporting models

    The tables dashboards read, with each metric defined

  5. 5

    Tests and docs

    Checks on every run, and a description for every column people use

Sound familiar?

If one of these is true, this work usually pays for itself.

  • The same metric is calculated in several dashboards, and they disagree.
  • Business logic lives in BI tool formulas or one-off SQL that only one person understands.
  • A source change breaks reports and nobody finds out until a manager asks.
  • You have a dbt project, but it grew without a structure and runs slowly.

What we build in dbt

  1. 01

    New dbt projects

    Staging, intermediate and reporting layers set up from the start, with naming, folders and run order your team can follow.

  2. 02

    Tests that catch bad data

    Uniqueness, null and relationship tests, plus record-count checks against each source, so a broken load stops before it reaches a report.

  3. 03

    Metric definitions

    Each business metric written once in a reporting model and documented, so Sigma, Power BI or Tableau all show the same number.

  4. 04

    Cleanup of an existing project

    Remove duplicate logic, move formulas out of the BI tool, speed up slow models, and document what each model is for.

Start with the decision, then trace the data

  1. 1

    Start from a number people argue about

    We pick a metric that two reports disagree on and trace it through the models to the source.

  2. 2

    Model it once, test it, document it

    The fix becomes a reporting model with tests and a written definition, and the reports switch to it.

  3. 3

    Hand over a project your team can run

    Code in your repository, runs on your schedule, and notes on how to add the next model.

Start with the problem

You don't need a finished requirements document. Start with a number the team doesn't trust, a report that takes too long, or a warehouse bill that keeps climbing.

Discuss your data problem