Reliability starts at the model layer: dbt tests on every mart, freshness and volume checks on source tables, and alerting wired into Slack or Cloud Monitoring before a stakeholder ever sees a wrong number. The goal is catching a break upstream of the dashboard, not downstream from someone asking why the figures look off.

Yes, and I don't default to a rebuild. I audit the existing dbt project and warehouse first (model sprawl, missing tests, partitioning, spend) and rank fixes by cost/effort before touching anything structural. Most stacks flagged as 'legacy' need targeted fixes, not a rewrite.

Through short discovery workshops to pin down what a metric needs to answer, documentation stakeholders can read without a data background, and a light governance rhythm (naming conventions, ownership, change alerts) so the platform doesn't silently drift once I'm off the mission.

Kestra or Airflow for orchestration, dbt for modeling and testing, Airbyte or dlt for ingestion, and Power BI or Looker Studio for the layer stakeholders actually see. Python fills the gaps standard connectors don't cover: validation scripts, custom monitors, one-off backfills.

On an ongoing mission for a large industrial group, I build tooling on top of an existing ODCS (Open Data Contract Standard) setup — governance by design rather than after the fact. Producers declare what a dataset guarantees, consumers know what they can rely on, and drift between upstream and downstream gets caught while a contract is being authored, not after it breaks a dashboard nobody can explain.

I run the target and source in parallel before any cutover: same models compiled against both engines, results diffed row-by-row on the critical tables, and a rollback path kept live until stakeholders trust the new numbers. The migration risk is almost never the SQL translation — it's the silent semantic drift between engines that nobody notices until a KPI moves.