Warehouse and dbt models
Snowflake, BigQuery, or Postgres, modelled in dbt. Every transformation has tests. Every model has docs and a named owner.
Pipelines and models you can trust on Monday morning.
Warehouses, pipelines, and the forecasting, scoring, and recommendation models built on them. Tested, versioned, monitored for drift, and owned by your team.
Data first, models second
Fix the data. Then predict with it.
Models are only as good as the tables under them. We build the warehouse layer first, then the models that read from it.
Ingestion with schema contracts
Producers publish a schema contract. A breaking change fails their CI, before it breaks a dashboard.
Orchestration
Dagster or Airflow schedules with retries, backfills, and partitions. A rerun is one command, not a war room.
Data quality and freshness
Freshness, volume, and null-rate checks on the tables people decide from. Alerts go to the table's owner, with lineage attached.
Forecasting, classification, recommendation
Demand forecasts, churn and fraud scores, and product recommendations. Trained on the warehouse you already trust. Served in batch or in real time, and measured against the baseline you use today.
MLOps and drift
Experiments tracked in MLflow. Champion–challenger promotion, shadow mode, and drift alerts on every model.
Data contracts
Catch breaking changes upstream, not in the dashboard.
Most broken dashboards start with a column someone changed in the app database. We put a contract between the teams that produce data and the warehouse that reads it. A change that would break a downstream model fails the producer's CI, with the affected models listed.
- Schema contracts versioned in the repo and owned by the producing team.
- dbt tests on every model: uniqueness, nulls, accepted values, relationships.
- Freshness and volume checks on the tables behind every key metric.
- Lineage from source column to dashboard tile, so impact is visible before merge.
Models in production
Catch drift before it costs you a quarter.
A model is only as good as last month's data. Customers change, inputs shift, and accuracy decays quietly. We monitor feature and prediction drift on every model we ship, with thresholds agreed with the business before launch.
- Feature drift: input distributions compared with training data, per feature.
- Prediction drift: output distributions as an early signal, before labels arrive.
- Label tracking: the real outcome, measured once it lands — sometimes weeks later.
- Retraining runs when a threshold trips, and promotion still needs to pass the eval gate.
Every model
Ships with tests, docs, and a named owner
Pre-merge
Contract checks block breaking schema changes
Shadow
New model versions run in shadow before promotion
Day 1
Code in your repo, data in your warehouse
The contract check failed the app team's pull request before the column rename merged. Finance never saw a broken number.
Questions
What buyers ask us first.
Do we need a data warehouse before machine learning?
Usually, yes. A model is only as reliable as the data feeding it, so we start with ingestion and modelling unless your data is already tested and fresh.
Which tools do you use?
Snowflake, BigQuery, or Postgres for storage; dbt for modelling; Dagster or Airflow for orchestration; MLflow for experiments. If your current stack is sound, we build on it.
How do we know a model is worth it?
We measure it against what you use today — often a spreadsheet or a rule. A model ships only if it beats that baseline on a holdout set the business agreed to.
Who owns the data and the models?
You do. Pipelines and models run in your cloud and your warehouse, and the code lives in your repository.
How is it priced?
A fixed scope for a defined pipeline or model, or a monthly rate for an ongoing data team. You get a written estimate after discovery.
Ready when you are
Tell us which number nobody trusts.
A 30-minute call. We'll trace it back to its source with you and say what we'd fix first.