"Do we have to keep expensive data scientists on payroll forever now?" What you actually need after delivery

Near the end of almost every data or ML project I hear the same question, and it usually comes from the owner, not the CTO: "So do we now have to keep these expensive data scientists on staff forever?" A reasonable fear sits behind it. They look at the specialist's rate, multiply it by twelve months and by years ahead, and see a bloated payroll for a system only a rare, expensive person can supposedly keep alive. And underneath that, a permanent lock to me as the contractor, if they have no such person of their own.

Let me answer it straight. The fear is reasonable, companies really do get caught this way. But it rests on one confusion: the work a data scientist does while building, and the work someone has to do after delivery, are two different jobs with two different price tags.

Where the fear comes from

A data scientist's rate is high because you are paying for the research part: pick the approach, understand your data, engineer the features, train and validate the model, throw out the five variants that did not work. That is expensive intellectual work, and during the build it genuinely is needed.

The mistake is assuming that because building the system was expensive, keeping it running costs the same and requires the same person. Usually it does not. Building a retraining pipeline and running an already-configured one are different tasks in both difficulty and cost. The first is done by a researcher. The second is often done by your ordinary analyst following instructions.

On how three different roles with three different salaries hide behind the phrase "data team", I have a separate note: it is time to tell the data scientist, analyst, and engineer roles apart.

What is actually expensive, and what is not

The expensive part of the project is one-time. It is the design: which approach to choose, which features to compute, how to validate the result, where the limits of applicability are. You pay for it once, and the product of that work is not a person on staff but a frozen, documented system.

The cheap part is the recurring one. Take fresh data, run it through the pipeline that is already built, look at the health metrics, retrigger retraining on schedule. That is operational work. It requires neither research-grade skill nor a research-grade rate. You can teach it to a person you already have.

The whole point of a clean handoff is to split those two parts honestly: do the expensive thing once and freeze it, put the cheap thing into your hands so you can do it yourself. There are two ways to arrange this. They do not exclude each other, and it is often a combination.

Path one: consume the result as a service

Here you do not keep a data specialist at all. You consume the result.

The configured system lives as a service: it has an input (your data) and an output (scores, a forecast, labelled records, a ready data mart or dashboard). You send the data, you get the result, and you pay for a service, not for a headcount. Who runs the machinery inside is the provider's concern, whether it is an off-the-shelf SaaS fitted to your task or analytics-as-a-service on my side.

When this fits:

• The task does not change every week and the data flow is stable.
• You care about the result, and the internal machinery as such is not something you need to own.
• Keeping a full-time data scientist for this is objectively more expensive than paying for a service.

There is one honest caveat, and I name it up front: a service is its own form of dependency. You are tied not to an expensive employee but to a provider and their platform. It is a fair trade, but it has an exit cost, and you should calculate that cost before you sign, not when you decide to leave. On that, a separate note: calculate the exit cost before you sign.

Path two: your own people rerun the configured pipelines

Here the system stays with you, but the person maintaining it is not a researcher, it is your existing analyst.

This works because the heavy part, the design, is already done and frozen. What is left for your person: run the pipeline on new data, read a few health metrics, notice when something has drifted, and know the moment to call me instead of fixing it themselves. That is checklist work, not research from scratch.

Companies often run a configured data warehouse perfectly well with their ordinary analysts, and the mechanics here are the same. I wrote about that in a data warehouse without a data team.

For a handoff like this to actually hold, rather than fall apart in a month, I do it in the same order every time:

1. Freeze the pipeline and version it. The configured retraining chain is captured whole: code, parameters, data versions. It is not a promise to "send the script later", but a working, reproducible system with a single run button.

2. Write the runbook for your person, not for me. What to run, when, what counts as normal, what counts as an alarm. Written in an analyst's language, not a researcher's. An instruction you can work from without understanding the math inside.

3. Set health metrics and thresholds. So that decay shows up on a dashboard, not through user complaints three months later. A model that has quietly drifted is more dangerous than one that has plainly broken.

4. Train one or two of your analysts hands-on. Not a one-hour presentation, but several real runs done with their own hands while I am next to them. The person has to rerun the pipeline and read the metrics themselves before I leave.

5. Draw the "call me" line explicitly. Where checklist operations end and the work that genuinely needs me or another specialist begins. Your analyst has to know not only what to do, but what not to touch.

6. Leave a thin link instead of a headcount. A small retainer for rare cases costs a fraction of a permanent expensive rate, and it is more honest: you pay for access to expertise when you need it, rather than keeping it idle on staff just in case.

Honest caveats

It would be dishonest to sell this as "deliver and forget". There are limits, and I name them before the start, not after.

• Models decay. Data changes, the world changes, and the accuracy of a configured model drifts over time. Someone has to watch for that, but it is monitoring work against metrics, not continuous research. On how it happens quietly, I have a separate note: ML models decay silently.

• Some problems need a researcher permanently. If your domain moves fast, if the model is the core of the product and a competitive edge, if every month needs a new approach rather than a rerun of the old one, then a full-time data scientist is justified. I will tell you honestly that this is your case, instead of selling a pretty handoff that will fall apart.

• If personal data runs through the pipeline, that is a separate layer. Retraining on customer data is also a compliance question, not only an accuracy one, and I look at that on its own terms rather than folding it into the model work.

Taking on something that genuinely needs a permanent team and selling it as "we will train your people in a week" is a way to lose both the reputation and the client. One honest "you need your own person here" comes back as trust.

In short

• The fear of "keeping expensive specialists forever now" rests on confusing two different jobs: building the system, and running the one already configured.
• The expensive part is one-time design. You pay for it once, and its product is a frozen system, not a headcount.
• Path one: consume the result as a service (SaaS or analytics-as-a-service) and keep no specialist at all. The caveat is the tie to the provider, so calculate the exit cost in advance.
• Path two: your existing analyst reruns the frozen pipeline from a runbook. The heavy work is done, what is left is checklist operations.
• A clean handoff is a freeze, a runbook, health metrics, hands-on training of your people, and an explicit "call me" line.
• There are cases where a full-time researcher really is needed. There I say so plainly.

If you are mid-way through a data project and already wondering what it turns into after delivery, that is the right moment to talk. A good handoff is designed from the start, not stitched on at the end. Feel free to get in touch; the first conversation commits you to nothing. </content>