Kaizen Gaming's dbt governance framework cuts new project setup time by 70%

Six teams, six ways of working

Kaizen Gaming is the company behind the sports betting and casino brand Bettano. According to dbt Labs, it operates in 25 markets across four continents, with more than 15 million active users and 40% year-over-year growth.

As the organization grew, each of its six analytics engineering domain teams adopted dbt at its own pace and on its own terms. The talk, given by principal analytics engineers Thomas Antonakis and Stefanos Nikolaou together with senior analytics engineer Akis Zervas, described three costly patterns that resulted:

• The same source data was staged independently in as many as six places, with no single definition anyone could point to.
• Shared infrastructure was copy-pasted instead of reused.
• Leadership had no visibility into test coverage or investment payoff, and onboarding a new hire meant relearning conventions that lived in several people's heads.

Three layers centralized, the rest left to domain teams

Instead of building a full platform team, the two principals chose exactly three layers to centralize.

Foundational models. A project the speakers call Core holds company-wide spine models as lightweight views with no orchestration overhead. Every downstream project references it.

Internal utilities package. Shared macros, tests and configuration are propagated to subscriber repos automatically through a subscription mapping file. A single merge now replaces what used to take 15 manually opened pull requests.

Infrastructure and AI tooling as code. dbt project and environment configuration moved out of the UI and into Terraform, using the dbt Labs Terraform provider. CI is scoped only to affected projects, merge and apply rights are limited to the two principals as code owners, and a separate manual approval step is required before anything applies to production.

On the AI side, the team built a central enablement repository with roughly 16 analytics-engineering-specific skills. These are wired into both their warehouse and dbt's MCP server, so every engineer's AI agent starts from the same context regardless of which tool they use.

Reported results and a rule for what to centralize

The speakers shared the following results:

• New project lead time down 70%.
• A $10,000 annualized savings from templated project setup.
• Roughly 15x time leverage on shared configuration fixes through the utilities package.
• AI onboarding for new hires cut from a multi-day, ad hoc process to about 30 minutes.

As evidence that the framework is an active system and not a document nobody opens, they pointed to fifteen merge requests against the shared repos in the 30 days before the talk.

The speakers also offered a decision rule. Something belongs in the shared layer when no single domain truly owns it, when every team would otherwise solve the same problem independently, or when the inconsistency is costly at the organization level rather than being real business logic. It stays with the domain team when it encodes actual business judgment or when getting it wrong only affects one team.

Access control for AI agents and what it means

Asked about access control for AI agents, the speakers said all of their analytics engineers share the same access level today. Authentication for agents connecting through GitLab, Atlassian or Databricks MCP servers is handled centrally by the platform team via SSO.

For other data teams facing the same drift between domain groups, the talk offers a concrete template: limit central control to a few clearly justified layers and keep business logic with the teams that own it. One of the speakers summed up the approach this way: "governance and autonomy do not need to be in conflict." The figures come from the speakers' own account of their work, as published by dbt Labs, and were not independently verified.