Who Runs Your Data System After the Build Is Done?

Who maintains a dashboard after the project is finished?

In most builds, you do. The honest structure for an analytics engagement is that the system lives in your accounts, under your credentials, with your data, so that if you never speak to the vendor again nothing breaks. CDA builds this way on purpose, and most reputable firms will tell you the same.

What that structure does not answer is who performs the upkeep. Refreshes fail. Credentials expire. A new data source needs a home. Somebody has to do those things, and “the client owns it” is a statement about property, not about labor.

What does “you own it” actually include?

It includes two transfers, and vendors usually only price one. The first is assets: the account, the code, the license, the credentials. The second is the operating burden, which almost never appears on a scope document.

We built a document processing system for a financial services firm exactly the right way. Their cloud account, their storage, their reporting license, every credential in their hands from day one. The build shipped and their first reaction was “That was fast!”

Then they had to run it, and the second transfer was the one nobody had costed.

What routine work does owning a data system involve?

Four kinds: keeping credentials and connectors alive, keeping file and folder structure correct, noticing when a refresh silently fails, and adding new data sources. Almost none of it is analysis.

On that engagement, in the weeks after handoff, it looked like this:

• Installing a database connector so their reporting tool could reach their own data warehouse. There are two families of connector that look interchangeable and are not. It took hours across several days.
• Noticing that a refresh had stopped working. The cause was a date written as 4/7/2026 instead of 2026-04-07. Nothing errored in a way that said so. The dashboard simply showed old numbers.
• Fixing calculated formulas that broke because a column header contained a slash.
• Creating a correctly structured folder in their own storage so a new customer’s data would flow through. They asked us for a video showing how.

Partway through, their team wrote:

They were not incapable. They solved things too, including that date format: “Figured it out. It was a date incompatibility… Sheesh!” They were an assigned owner without the specific technical depth the system assumed, which is a scoping failure, not a personnel failure. Ours.

Your version of this looks different but fails the same way. If your system pulls from a field service platform, a call tracking line, and an ad account, a software update renames a field and a report quietly empties. A new location’s jobs land under a name nothing else recognizes. A technician export stops matching because someone changed a status label. None of it announces itself. You find out when a number looks wrong in a meeting.

How do I know if my team can actually operate it?

Run this test before you sign, not at handoff. It takes about an hour.

1. Name the operator. Not a team, not a role. A person. If nobody can be named, the answer is already no.
2. List the routine tasks the system will require. Ask the vendor to write them out: refreshing data, adding a source, rotating credentials, fixing a failed load.
3. Rate that person against each task honestly. Not “could they learn it” but “could they do it on a Tuesday without calling anyone.”
4. Price their time. How many hours a month, and what does that displace? An hour a week from an office manager is real money and a real trade.
5. Ask what happens when they leave. If the answer is that the knowledge leaves too, the handoff was never finished.

If the honest answers are uncomfortable, the design changes. That is cheaper than discovering it three weeks after go live.

What does it cost when a handoff fails?

It gets paid either way, just later and by whoever has less leverage. On our own project it came out of our margin as unbilled support. On a project where the vendor holds firmer, it comes out of the owner’s week in hours nobody budgeted, or out of the system itself when people quietly go back to spreadsheets and the thing you bought becomes a screen nobody opens.

The cost of scoping enablement up front is always smaller than the cost of finding it after go live.

Is this the same as deciding whether to hire an analyst?

No, and conflating them is common. Deciding whether you need analytics help is a question about analysis capacity, and the answer is often that your existing person is capable but out of hours. That is a bandwidth question, and we have written about it separately.

This is a different skill. Reading a dashboard and interpreting what it says is analysis. Installing a driver, structuring a storage path, and recognizing a format mismatch is infrastructure operation. A person can be genuinely good at the first and have no reason to be good at the second.

Should you own it, operate it, or both?

They are separable decisions, and treating them as one is how owners get stuck. You can own every asset outright and still pay someone to run it. Ownership protects you from being trapped. Operation is a job that has to sit somewhere.

A vendor operating a system you own is not lock in, provided the assets and access stay yours and you can end the arrangement without losing anything. It is worth checking their terms before you sign.

What should a good handoff include?

Four things, and they belong in the estimate rather than in goodwill after the fact.

• Documentation written for the named operator, at their actual level, not at the builder’s.
• A recorded walkthrough per routine task. Short videos beat manuals for work somebody performs once a quarter.
• A rehearsed dry run where your operator performs every routine task unaided while the vendor watches and says nothing. Whatever they cannot do is a gap found while the vendor is still engaged.
• A defined support window after go live, with its end date stated.

What to do before you sign

Ask whoever is selling you an analytics build who will operate it on an ordinary Tuesday eight months from now, and what happens to that person’s week when it breaks. If they have not thought about it, you have found the part of the project nobody has priced. That is not a reason to walk away. It is a reason to get it scoped and costed alongside everything else.

That test came out of getting it wrong. We price enablement into the estimate now rather than absorbing it afterward, because the alternative was paying for it ourselves and calling it a lesson.

If you want a second opinion on a build you are considering, send us a note. No pitch, and if the answer is that you do not need what you are being sold, we will tell you.

Frequently Asked Questions