Having dbt doesn't mean you have a good data model. That was the blunt message Silja Märdla, head of analytics engineering at Bolt, opened her dbt Summit 2026 session with. The European "super app" for rides, delivery and rentals had adopted dbt with few rules in place - fine while the team was small, but it broke down once the team passed 20 people last year. Teams staged the same data differently, informal guidance was read inconsistently, and answers from the analytics engineering team began to diverge.
Over several months the team whiteboarded and jointly signed off on an explicit set of 14 written rules. Among them: every table exposed to consumption tools must take one of exactly three shapes - a single-entity table, a slowly changing dimension, or a combination of entities, usually with time - and exposed tables should be simple selects over intermediate models rather than carrying business logic. Intermediate models are likewise limited to three shapes: spine (identifiers and raw attributes), feature (derived business logic on an entity) and metrics (aggregated values on a grain). Metrics are kept separate because they are auto-generated from centralized definitions; a metric defined once against its source fact table and aggregated at another grain is called a feature, not a second copy.
No dbt model has shared ownership, and project dependencies run one way, mirroring the business: a vertical team such as rides, delivery or rentals can read from a horizontal team's project like billing or geo, never the reverse, with shared logic pushed upstream into a common project instead of duplicated downstream. Metrics that can't legally be re-aggregated across grains, such as distinct counts, get their own marts away from additive metrics; Bolt's BI tool requires a "metric key" field whenever a non-additive metric is selected, to prevent wrong aggregations that would otherwise pass without error.
The rules have held for about six months without major issues. Märdla stressed the discipline of writing them down over the specifics, returning to lines like "the fact that you do have dbt doesn't mean your data model is good" and "there is no shared ownership of a dbt model." Bolt's structure guide echoes dbt Labs' own best-practices guide on staging, intermediate and marts layering for teams drafting their own rule set.
Source: dbt Labs Blog