Data Stack Diagnostic

How the Diagnostic Works

Before a global SaaS platform’s 45-day rebuild — the one that ended with 606% Year-1 ROI and revenue validated to 0.002% — there was a counting exercise. Every legacy object inventoried: 377 of them, traced, classified, and mapped to the 51 dbt models that would replace them. That inventory is what made a fixed-scope, fixed-date quote possible. The diagnostic is that exercise, productized.

What actually happens in the two to three weeks

We inventory the stack object by object: every dashboard, report, scheduled query, and pipeline — who consumes it, what feeds it, what breaks silently when it is wrong. Lineage gets traced to source systems. Complexity gets measured, not estimated. In most stacks we audit, a large share of the objects answer questions nobody is asking anymore — knowing which ones is where the rebuild’s economics come from.

Then we assess AI readiness: whether your metric definitions could support a semantic layer today, where the data quality gaps are, and what “LLM on our data” would actually require in your stack — a question most teams are being asked by their board right now and cannot answer with evidence.

What you walk away with

The findings document, the migration and AI-readiness roadmap, and a fixed-price, fixed-date quote for the rebuild. Every finding is verifiable against your own systems — this is the same evidence standard as our delivery work, applied to the assessment itself.

If you proceed to the build, the diagnostic’s inventory becomes the rebuild’s validation baseline: the list every migrated number gets reconciled against. Nothing is thrown away.

When to skip it

If your stack is small and your team already knows exactly what it needs, a diagnostic adds a step you may not need — we will say so on the strategy call. And if you have a dated trigger already burning (a license sunset in eight weeks), we fold the diagnostic into the build as its first milestone instead of running it standalone.

Three questions to ask yourself

Could anyone in your company say, today, how many reports and models your stack actually runs — and how many are still used? If the board asked “what would AI on our data take,” would the answer be evidence or a guess? When was the last time a migration estimate you received survived contact with the actual system?