Free · No signup
The Data Platform Teardown
The 18 questions I ask in a paid audit. Run them yourself — most teams find something expensive in the first hour.
I charge $3,000 to run this against a client's stack for a week. The questions themselves aren't the expensive part, so here they are — all 18 of them, with what a bad answer sounds like. Work through them with your team; you don't need me for that.
Where the money goes
Warehouse bills rarely grow because of one bad decision. They grow because elastic pricing quietly rewards leaving things on. Start here — it is where the fastest wins are.
What is your compute-to-storage split?
Bad answer: Compute is more than ~70% of the bill. That means you are paying elastic, per-second pricing to run what is actually a steady, predictable workload — the case elastic pricing is worst at.
What is the auto-suspend setting on each warehouse, and how often is it actually queried?
Bad answer: A 10-minute auto-suspend on a warehouse something touches every 9 minutes. It never suspends, and you are billed as if it were always on — because it is.
What is your single most expensive query, and who reads its output?
Bad answer: Nobody can tell you. In practice it is usually a dashboard refreshing on a timer for a team that stopped opening it months ago.
Do dev, staging and CI run on the same meter as production?
Bad answer: They do, and nobody has ever measured what share of the bill they are. A test suite that spins up a Large warehouse per run is a real line item.
Which models rebuild from scratch every run, and do they need to?
Bad answer: Full refreshes on tables where only the last day changed. This is the most common single source of avoidable compute spend.
Which tables have not been read in 90 days?
Bad answer: You cannot answer it. Most warehouses have query history — if nothing reads a table, you are paying to store and often to rebuild it.
Whether the numbers are right
Cost problems are embarrassing. Correctness problems are expensive in a way that shows up in decisions, not invoices — and they surface months late, usually in a board meeting.
Is "revenue" defined in exactly one place?
Bad answer: It is defined in the warehouse, again in the BI tool, and a third time in a finance spreadsheet — and the three do not agree. Whoever is asked last gets believed.
What happens when a source file arrives late or not at all?
Bad answer: The pipeline succeeds with yesterday's data and nobody is told. Silent partial success is far worse than a loud failure.
Is every load idempotent — can you re-run it twice safely?
Bad answer: Re-running a job duplicates rows, so re-runs need manual cleanup first. This makes recovery slow exactly when you are under pressure.
Is there one documented timezone convention?
Bad answer: Some tables are UTC, some are local, and the convention lives in one engineer's head. Daily aggregates will be wrong at the boundaries and nobody will notice for a quarter.
Are there freshness and row-count checks on every source table?
Bad answer: Checks exist on the tables someone was already worried about, and nowhere else. Coverage that follows past incidents only catches repeats.
Whether it runs without you
The question is not whether pipelines fail — they do. It is how long it takes to find out, and whether finding out depends on a person remembering to look.
How long between a pipeline failing and a human knowing?
Bad answer: Someone notices a stale dashboard. If your detection path runs through a human opening a chart, your real detection time is measured in days.
Do failures retry with backoff, or wait for a manual re-run?
Bad answer: A transient API timeout at 2am means the day is lost until someone re-runs it by hand in the morning.
Can you re-run a single day without re-running everything?
Bad answer: Backfilling one bad day means a full historical rebuild. This turns a small fix into an expensive, risky, all-day operation — so it gets postponed.
What is alerting on, and who actually receives it?
Bad answer: Alerts go to a channel everyone muted, because it also carries every successful run. An alert nobody reads is not monitoring.
Whether you can change it safely
A platform that works but cannot be changed is a platform on a timer. This section is about how much of the system exists only as habit.
Is all of it in version control, and does CI run on a pull request?
Bad answer: Some transformations live in the warehouse UI or a scheduled notebook. Anything not in git is undocumented and unreviewed by definition.
Can a new engineer run the pipeline locally on day one?
Bad answer: Local development is not possible, so every change is tested in production. This one answer predicts the rest of the audit better than any other.
How long from "add a column" to it appearing in a dashboard?
Bad answer: Weeks, and it requires the one person who knows the chain. Measure this honestly — it is your platform's real cycle time.
Want this as a working doc?
I'll email you the whole checklist in plain text — paste it into Notion, Linear or a doc and work through it with your team. Same 18 checks, nothing held back.
One email, sent immediately. No sequence follows it. Reply and you reach me directly.
If you'd rather not run it yourself
That's the Data Platform Audit — one week, $3,000 fixed, and I do the work: read-only access, about two hours of your team's time, and you get a ranked fix-list, a cost model and a small proof-of-concept on your own stack.
If it doesn't surface fixes or savings worth more than the fee, you don't pay — and the fee comes off any follow-on build.
Book a free 30-minute scoping call