What a Data Stack Diagnostic Actually Is — and When You Need One
- SaaS & Tech
- Finance, Fintech & Investment
TL;DR
A data stack diagnostic is a paid, fixed-scope assessment that runs two to three weeks inside your actual systems: every dashboard, report, scheduled query, and pipeline inventoried; lineage traced to source; complexity measured rather than estimated; AI readiness assessed against your real metric definitions. You end with three artifacts — the stack inventory, the findings document, and a migration and AI-readiness roadmap closed with a fixed-price, fixed-date quote for the rebuild. It is not a free assessment, and it is not a rebuild. It is the counting exercise that makes quoting a rebuild possible without guessing. We call it the Data Stack Diagnostic — in Spanish, La Radiografía de Datos.
Key takeaway — A data stack diagnostic is a fixed-scope, two-to-three-week assessment run inside your real systems, ending with an inventory, a findings document, and a fixed-price, fixed-date quote for the rebuild. This post defines the term, covers what it includes, what it deliberately is not, and the three trigger moments that usually make one urgent.
Most data projects that go wrong start the same way: someone estimates. They estimate how many reports need migrating, estimate which ones are still used, estimate how long it takes. Six weeks in, the scope turns out to be double, and the conversation with the vendor stops being about data and starts being about the contract.
The fix is not estimating better. It is counting.
That counting exercise, productized into an engagement with its own scope, date, and price, is what we call the Data Stack Diagnostic — in Spanish, where most of our clients buy it, La Radiografía de Datos, the X-ray. The metaphor holds up: it is not an interview about how the stack feels, it is an image of what is actually inside it.
What is a data stack diagnostic?
A data stack diagnostic is a paid, fixed-scope assessment of your data platform. It runs two to three weeks, happens inside your actual systems rather than from what your team believes is in there, and produces three artifacts: the stack inventory, the findings document, and a migration and AI-readiness roadmap closed with a fixed-price, fixed-date quote for the rebuild.
The distinction that matters most: it is delivery, not pre-sales. What you get is a document your team can act on with or without us.
Vendors use several names for adjacent things — data maturity assessment, BI audit, discovery phase. The useful test is not the label. It is whether anyone opened the systems and counted.
What does a data stack audit include?
Four things happen in those two to three weeks.
An object-by-object inventory. Every dashboard, report, scheduled query, and pipeline: who consumes it, what feeds it, what breaks silently when it is wrong. Not a representative sample — all of them.
A lineage audit. Lineage traced back to source systems, so that for any number on any report, you can say where it came from and how many hands it passed through before it reached your CEO’s screen.
A complexity measurement. Complexity gets measured, not estimated. That difference is what makes quoting without padding possible. In most stacks we audit, a large share of the objects answer questions nobody is asking anymore — knowing precisely which ones is where the rebuild’s economics come from.
An AI-readiness assessment. Whether your metric definitions could support a semantic layer today, where the data quality gaps sit, and what “LLM on our data” would actually require in your stack. Most boards have already asked. Very few teams can answer with evidence.
The cost to your side is deliberately small: read access to your BI and warehouse, one working session with the people who own the numbers, and a short review at the end.
How long does a data stack assessment take?
Two to three weeks. The range tracks stack size and lineage complexity, not how busy your team is.
Two to three weeks sounds short for “inventory everything,” and the skepticism is fair. It works because the scope is hard-edged: we count and trace, we do not repair. Nothing gets rebuilt during the diagnostic. That discipline is exactly what makes the date committable.
Who is it for?
The CFO, CDO, head of data, or COO of a mid-market company that already has a stack — inherited, patched, several years deep — and whose next decision is expensive.
If any of these describe your situation, it is for you:
- Nobody in the company can say, today, how many reports and models your stack actually runs.
- You have a migration quote in hand and no way to judge whether the number is serious.
- Someone upstairs asked what AI on your data would take, and the honest answer was “I don’t know.”
And if your stack is small and your team already knows exactly what comes next, we will tell you so on the strategy call. The diagnostic adds a step you may not need.
What a data stack diagnostic is not
Three things worth ruling out up front.
Not a sales audit. Not a free assessment whose real product is the proposal that follows. Free assessments produce slideware calibrated to sell the next phase; a paid diagnostic is calibrated to be right. If you decide not to continue, you keep everything.
Not a rebuild. Nothing is migrated, no models are rewritten, no dashboards are redone during the diagnostic. It is assessment. Blurring the two is how a three-week engagement quietly becomes a three-month one that nobody actually approved.
Not a strategy workshop. We are not facilitating sessions where your team fills a wall with sticky notes about its data vision. Counting and tracing is our job. Your team shows up for one working session and one review.
When do you need one? Three trigger moments
Nearly every diagnostic we run starts with one of three triggers.
1. A license sunset. Your legacy BI tool has a death date — an impossible renewal, end of support, a price increase that no longer clears committee. Suddenly there is a calendar you do not control, and you need to know how much of what runs in there genuinely has to come along.
2. A forced migration. ERP replacement, a merger, a parent company mandating a platform, a vendor discontinuing the product. The decision is already made above you; what is missing is the real scope and a date that will survive contact with the system.
3. “We want AI on our data” — with nobody to build it. The most common trigger right now. Someone on the board asked, the team said yes, and the conversation stalled on the first technical question: are our metrics defined in one place? The answer is usually no, and finding that out with evidence takes two weeks instead of two quarters.
There is a quieter fourth case, and it is the healthiest one: you are about to ask for rebuild budget and you want to walk into the committee with a number you can defend line by line.
What you walk away with
Three artifacts, all verifiable against your own systems:
- The stack inventory — every report, model, and pipeline, traced and classified.
- The findings — what is redundant, what is fragile, what blocks AI on your data.
- The roadmap and the quote — the migration and AI-readiness plan, closed with a fixed price and a fixed date for the rebuild. The scope we agree on is the scope we deliver.
If you proceed to the build, the inventory is not filed away: it becomes the rebuild’s validation baseline, the list every migrated number gets reconciled against.
This is what a rebuild that started from that counting exercise looks like: 377 legacy objects turned into 51 dbt models in 45 days, with revenue validated to 0.002% and 606% Year-1 ROI. The inventory is what made quoting those 45 days possible before a line of code was written.
What does it cost?
We do not publish a price, and it is worth saying why rather than pointing you at a form.
The scope of a diagnostic depends on the real size of your stack — how many objects there are to count and how tangled the lineage is — and that number cannot be guessed from a web page. What is fixed is the mechanism: it is quoted at a fixed price and a fixed date on the strategy call, before anything starts, and that price does not move during the engagement. No billable hours, no mid-flight change orders.
It is paid on purpose. A free assessment always ends up calibrated to sell what comes next; a paid one can afford to conclude that you do not need to rebuild anything.
If the clock is already running
When a deadline is already burning, there is no need to run the diagnostic standalone. We fold it into the build as its first milestone — the inventory and validation baseline have to exist either way, so they get built inside the project instead of ahead of it.
And if you are still comparing vendors, the guide to what to ask a data consultancy before you sign works on any proposal, not just ours.
The service page has the full mechanics. If you want to know what yours would take, a strategy call is enough to find out — you leave with a range, not a twenty-page proposal.
Frequently asked questions
What is a data stack diagnostic?
A data stack diagnostic is a paid, fixed-scope assessment of a company's data platform, run inside the actual systems rather than from interviews. Over two to three weeks it inventories every dashboard, report, scheduled query, and pipeline, traces lineage back to source systems, measures complexity, and assesses whether the stack could support AI on its data today. It ends with three deliverables: the stack inventory, a findings document verifiable against your own sources, and a migration and AI-readiness roadmap with a fixed-price, fixed-date quote for the rebuild.
How long does a data stack assessment take?
Two to three weeks. That is calendar time, not your team's effort: from your side it takes read access to your BI and warehouse, one working session with the people who own the numbers, and a short review at the end. The counting, tracing, and classifying is the consultant's job, not a workshop your analysts have to carry on top of their day work. The range depends on stack size and lineage complexity, and it is committed before the engagement starts.
What does a data stack audit include?
Four workstreams and three deliverables. The work: an object-by-object inventory of the stack, a lineage audit tracing every number back to its source systems, a complexity measurement (measured, not estimated), and an AI-readiness assessment of your metric definitions and data quality gaps. The deliverables: the full inventory with each object traced and classified, the findings document covering what is redundant, what is fragile, and what blocks AI on your data, and the roadmap with a fixed-price, fixed-date quote for the rebuild.
Why should a data stack diagnostic be paid rather than free?
Because it is delivery, not a sales call. A paid diagnostic goes into the real systems, counts and traces every object, and hands over findings the client can verify against source — a document their team can act on with or without the consultant. Free assessments produce slideware calibrated to sell the next phase; a paid diagnostic is calibrated to be right, which includes the freedom to conclude that no rebuild is needed.
Do I need a diagnostic if I already know what to build?
Possibly not as a standalone engagement. If the stack is small and the team already knows exactly what it needs, a diagnostic adds a step — we will say so on the strategy call. And when a dated trigger is already burning, like a BI license sunset in eight weeks, the diagnostic gets folded into the build as its first milestone instead: the inventory and the validation baseline have to exist either way.
What happens to the diagnostic's work if we proceed to the rebuild?
The inventory becomes the rebuild's validation baseline — the list every migrated number is reconciled against. Nothing is discarded. That is the mechanism behind revenue validated to 0.002% on a 45-day platform rebuild: the counting done up front is what makes the result auditable at the end.