Frequently Asked Questions

Four services in one discipline: dbt model development, data platform architecture, reverse ETL pipelines, and data quality and observability. If your question is about analytics engineering or the AWS data platform underneath it, it is in scope.

A principal engineer delivers every engagement, and the person who scopes the work writes the code. When a scope needs more than one engineer, the proposal says so, with the roles involved and the time each one spends on the work.

A call to understand the problem, then a written scope with deliverables and a fixed price or an agreed rate. For a dbt audit, that is a five-day fixed-price engagement and the scope fits on one page. For larger work, expect a scoped proposal within a week of the first conversation.

The dbt pipeline audit is EUR 2,500 fixed, five business days. Every contract takes a 30 percent deposit before work starts, regardless of size, and the balance is invoiced against agreed milestones. Day rate and ongoing engagements are quoted directly against scope.

dbt for transformation. Redshift and Snowflake at the warehouse layer, PostgreSQL below that. Python and SQL for everything else. On AWS: Lambda, ECS, S3, Step Functions for orchestration, and Terraform for the infrastructure around it. Docker and GitHub Actions for CI. If your stack differs, say so on the first call and you will get a straight answer on fit.

Senior-level Snowflake warehouse operations: credit management, clustering strategy, RBAC hierarchy design and Snowpipe. The Snowflake work here is the schema layer, including hybrid tables in production, not warehouse governance. That distinction is stated on the dbt page as well, because a client discovering the gap mid-project costs everyone more than reading it here.

Read access to your dbt project, five business days, and three deliverables: the top ten issues ranked by risk, two to three models refactored as a working example of the fix, and a written report your team can act on without us in the room. Broken tests, untested critical models, naming and structure drift, and missing documentation on load-bearing models are what it usually turns up.

Yes, and that is the usual shape. Your conventions get adopted rather than replaced, and documentation is generated from the dbt project itself so it survives the engagement ending.

Written updates by default, on whatever tool you already use. Async-first, from a European timezone with afternoons overlapping US East Coast mornings. No standing status meeting unless you want one.

Handover covers documentation and a walkthrough of what changed and why. Every project ships with dbt docs generated from the project and tests running in CI, which is the part that keeps working after the engagement ends. Ongoing support is arranged separately if you want it.