How customer pressure pushed dbt past a cautious platform team at Delivery Hero

At a dbt Summit 2026 breakout session titled "The Platform Team said no — dbt won with 'Yes' - story of governance, autonomy, and Scale," M. Waqas Shahid, of Delivery Hero's data platform team, described how dbt adoption at the company was driven by customer teams pushing against platform caution rather than handed down from above.

Delivery Hero is one of the world's leading local delivery platforms, operating in around 65 countries through a decentralized network of seven regional platforms and brands such as foodpanda in Asia. Founded in Berlin in 2011, the company now processes more than 11 million orders a day, or roughly half a million an hour.

The scale of Delivery Hero's data platform is substantial: about 300,000 tables holding 60 petabytes of data, roughly 140 million queries a month processing about 1,300 petabytes, and around 250 dbt projects spread across 45 decentralized teams the company calls Domain Data Units. Those teams collectively maintain 1,300 macros imported into 15,000 models and SQL scripts, running 23 million monthly tasks.

Before dbt, Delivery Hero's platform team built an in-house framework called DataHub that let teams scaffold a workflow, write parameterized SQL with Jinja templates, and configure dependencies and metadata in YAML. It worked for years, but customer teams eventually reported it was hard to debug, slow to develop against, and had a steep learning curve for new hires.

The platform team's first real exposure to dbt came through a GCP customer roundtable where they met engineers from Monzo, a UK bank that had already archived its own dbt fork by 2019 in favor of an internal tool nicknamed "DOM's Data Build Tool," built because dbt reportedly slowed down once a project passed 3,000 models. That experience led Shahid to conclude the tool wasn't ready for an organization of Delivery Hero's size, so the platform team paused.

By 2023, individual teams had started testing dbt on their own, and by mid-2023 there was an organized push from those teams to integrate it into the platform. In the second half of 2024, Delivery Hero merged with a team that had already fully adopted dbt, and by October 2024 an internal RFC was circulating to standardize dbt company-wide, all before the platform team had taken any action itself.

Customer teams did not wait for the platform team to act. They built and maintained their own Python package, called dbtflow, that converted dbt manifests into Airflow tasks and DAGs, and the platform team never owned it.

When Astronomer released version 1 of its open source Cosmos project in mid-2023, doing much the same manifest-to-Airflow conversion, Delivery Hero retired dbtflow rather than keep maintaining a duplicate. The platform team's own work narrowed to a CI layer of GitHub workflows, including a script called Cosmos Injector that adds priority weights to dbt manifests for Airflow task scheduling and uploads those manifests to a GCS bucket.

The team that merged in during 2024 brought a more declarative model: a "data product builder" defines a data product through an SDK without touching dbt or YAML directly, and an internal Mesh Hub API converts that submission into an Airflow DAG. dbt still powers the result underneath, just fully abstracted from the end user.

Shahid framed Delivery Hero's ongoing platform decisions around four recurring trade-offs. The first, abstraction versus flexibility, showed up whenever a fully abstracted pipeline failed with an unhelpful error and no way to debug it; dbt macros resolved this by letting teams import centrally governed rules for access control and policy tagging while still writing their own macros for anything team-specific.

The second trade-off, standardization versus autonomy, centered on ownership in a decentralized organization where nobody could say who to contact when a table broke. Requiring an owner tag on every dbt model, enforced in CI so unowned models can't reach production, fixed that by letting the platform tag the right person in Slack automatically when a job fails.

The third trade-off, self-control versus central control, involved analysts scheduling queries directly in the BigQuery console instead of through the central orchestrator, which made dependencies and compute spikes impossible to track. The dbt CLI gave analysts a fast, version-controlled way to build and test locally instead, centralizing more of the codebase without slowing anyone down.

The fourth trade-off, speed versus stability, is the classic tension between a platform team that wants staging environments and testing before production, and domain teams frustrated by slow deployments. Combining dbt tests, unit tests, and the dbt CLI with Cosmos running dbt as native Airflow tasks let tested models reach production through the existing orchestration tooling without adding deployment friction.

Shahid closed with two lessons he said apply beyond dbt: embrace tooling change deliberately rather than resisting it or chasing every new stack, an idea he called "evolving with intent," and remember that readiness has to exist at both the tool level and the organizational level. He pointed to Monzo's early, intimidating dbt fork as a case where Delivery Hero was right to wait before its own teams were ready, and argued platform teams should treat their "golden path" as a living standard, absorbing workarounds back into it over time rather than treating it as fixed.

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