How Kramp cut analyst onboarding from days to minutes with a self-serve dbt Mesh factory

Trang Trinh, senior data engineer at Kramp, presented at dbt Summit 2026 how her central data team scaled dbt Mesh across the business using an internal tool called Data Project Factory. Kramp is Europe's largest wholesaler of spare parts and accessories for agriculture, forestry, grounds care, and construction, founded in 1951 and operating over 500,000 products across 11 distribution centers and 24 sales offices. Trinh joined the company as it began adopting dbt platform on top of Google BigQuery, using Terraform to provision infrastructure.

The team's starting problem was familiar: a small central team owned all data infrastructure and became a bottleneck, fielding dozens of domain requests a week. As a stopgap, analysts began building their own unversioned BigQuery queries under personal credentials, creating what Trinh called a "shadow BI wild west," including scheduled jobs that silently broke once the analyst who created them left the company. Compounding both problems, the central team held superuser access to everything, including sensitive customer and payroll data.

An intermediate step, a central landing zone that unified raw source data before handing it to domain teams with more autonomy, plus lint-based CI guardrails, helped resolve the shadow BI problem but left onboarding and infrastructure control centralized, so the operational backlog and security exposure remained. Data Project Factory, a Terraform module, was built to resolve what remained. Given just a team name and owner email, it provisions a GCP project, a dbt project, and three GitHub repositories for that domain: one managing dbt platform infrastructure (environments, jobs, and variables), one holding the domain's dbt project template and CI setup, and one managing that domain's access permissions.

This delivered on four pillars of data mesh that Trinh credited to Google Cloud's framework: domain-oriented ownership, where projects carry no inherited superuser roles and confidential data no longer has to route through a central landing zone; data as a product, discoverable through dbt Catalog, with only each domain's presentation layer exposed for other teams to reference; a self-serve platform, so domain teams provision and manage their own resources; and federated governance, enforced through CI checks tied to each pull request and a maturity scoring framework designed to encourage teams to keep improving. Getting there took roughly two years across three migrations: moving the transformation layer from Dataform to dbt platform across 1,400 sources and 5,000 models without breaking downstream usage, rebuilding infrastructure through Data Project Factory to eliminate legacy superuser access, and an ongoing shift from ad hoc custom queries into governed dbt projects. A later infrastructure move, from dbt platform on AWS to GCP, covered 25 dbt projects in two weeks with no major issues.

The resulting numbers: 25 dbt platform projects and 50 licensed developers spread across 15 domain teams, with a single Terraform configuration now able to provision a secure, production-ready domain data product within minutes, no Terraform knowledge needed. An internal developer experience survey put satisfaction at 4.6 out of 5, with analyst onboarding down from days to minutes and time-to-insight down from weeks to hours. Trinh said the central team now spends less time on ad hoc requests and more time improving the platform itself.

Looking forward, Kramp wants one AI agent per domain, reachable from any interface and grounded in a unified, governed semantic layer shared across agents and BI tools; today that's an early-stage pilot built on Snowflake Semantic Views and Cortex Analyst.

Q&A ran long and covered implementation detail: onboarding analysts who are strong in SQL but new to dbt and Git (addressed through internal training, dbt Studio, and CI feedback via SlimCI and lint checks), what still lives in the central landing zone (latest-record logic only, with heavier transformation owned by each domain), how cross-project references are scoped and enforced (dbt's cross-project ref function, paired with service-account permissions and a lint rule restricting references to a domain's presentation layer only), how domain teams without deep data skills are supported (ongoing training plus dbt Wizard), and the limits of what Data Project Factory itself provisions (the base dbt project only, not environments, jobs, or schema, which are configured separately through each domain's Terraform repo).

Watch every keynote and breakout from dbt Summit 2026 on demand. Watch dbt Summit 2026 on demand →