You have an AI system that works, or one that nearly does, and a decision in front of you that reads like a pricing question. Do you buy another build, or do you put someone on retainer? The catalog makes it look like a choice between a project and a subscription. It is not — it is a choice about which failure you are insuring against.
A build is insurance against the system not existing. A retainer is insurance against the system existing and nobody being responsible for it. Those are different exposures, and a buyer who names the wrong one pays for the wrong protection: a fixed-scope engagement spends itself discovering that the real problem was never bounded, or a monthly engagement starts before there is anything live for a standing owner to stand over.
ML LABS sells both, and runs both. The practice designed and built the cloud backend of the AI-ECG platform at HeartSciences, a medical-device company whose platform is in clinical production — and it runs an ongoing engineering retainer for the same company today. Delivery first, then ownership: that sequence is not a theory about how the ladder should work, it is the literal history of that engagement, and it is where the argument below comes from.
Three Tests Before You Sign
graph TD
A["Can you name the system<br/>that has to exist?"] -->|"Not yet"| F["Scope it first"]
A -->|"Yes, and it does not"| B["Buy the build"]
A -->|"It already runs"| C["Is the scope of what<br/>needs owning fixed?"]
C -->|"One defined scope"| D["Buy Operate"]
C -->|"Priorities keep moving"| E["Buy the retainer"]
style A fill:#1a1a2e,stroke:#ffd700,color:#fff
style B fill:#1a1a2e,stroke:#0f3460,color:#fff
style C fill:#1a1a2e,stroke:#ffd700,color:#fff
style D fill:#1a1a2e,stroke:#0f3460,color:#fff
style E fill:#1a1a2e,stroke:#16c79a,color:#fff
style F fill:#1a1a2e,stroke:#0f3460,color:#fff- The output test. Can you write the deliverable in one sentence, and would a stranger know when it is done?
- The continuity test. Will the next three decisions depend on the context of the first one?
- The portfolio test. Is it one system that needs watching, or several that need arbitrating between?
Pass only the first and you are buying a build. Pass the second and third and you are buying ownership. Pass none of them and no contract will save you, because the thing being bought has not been decided yet.
Buy the build when the output is nameable. Buy ownership when the next three decisions matter more than the next deliverable.
What Each Contract Actually Buys
A production workflow build is $45K and buys a defined system, targets written into the contract before work starts, and a clean end. The guarantee is anchored to acceptance: you cancel for a full refund at any point before you accept against those written targets. The build carries its own run-in period — every Build on the ladder includes its Operate window, 30, 60, or 90 days by tier, run by the person who built it. Then it ends, on purpose.
Operate is priced monthly because what it buys does not end. The first step, at $15K/mo, puts an accountable owner on a defined scope of live systems: monitoring, drift and cost review, incident response, and a monthly written brief on what ran, what changed, and what is at risk. The second step, at $30K/mo, is embedded ownership of the whole live portfolio — the same work across every system, plus one active workstream carried or unblocked each month, a monthly strategy session, and async decision support on the architecture and vendor calls that otherwise sit in a queue. Both steps cancel with 30 days' notice, prorated, with no lock-in. The guarantee is on the work, not on the relationship.
The reason the shapes differ is in the shape of the systems. Research on hidden technical debt in machine learning (NeurIPS, 2015) makes the point that model code is a small fraction of what a production ML system is actually made of; the rest is configuration, data plumbing, monitoring, and glue, and all of it has an owner or it has an entropy budget. A case study of software engineering for machine learning (ICSE, 2019) found that ML components entangle with the rest of the system in ways ordinary features do not, which is why maintenance on them is not the same activity as maintenance on a CRUD endpoint. A fixed-scope contract prices the first delivery of that surface. A monthly contract prices its continued existence.
What Decays After Handoff
A delivered AI system is not a finished one. Inputs shift and the model's accuracy quietly follows them down. Usage rises and the inference bill rises faster than anyone modeled. Failures stop being loud, because a loud failure is the kind that gets caught before launch — what survives into production is the class that returns a plausible wrong answer. And the person carrying the design in their head, the one who knows why the retry logic is shaped the way it is, moves on to the next thing. A survey of machine learning deployment case studies (ACM Computing Surveys, 2022) catalogs how much of the difficulty in production ML sits after the model works, and research on data lifecycle challenges (ACM SIGMOD Record, 2018) shows the data feeding a live system is itself a moving target that needs managing.
None of that announces itself. On a hedge-fund engagement, ML LABS found a data pipeline that had been accumulating volumes of unnecessary and polluted data nobody had looked at, while the aggregation step upstream was discarding information the models actually wanted. Once someone looked, storage costs came down by more than 60% and the models scored 2% better — the full account, and what it says about ownership over time, is in the case for systems that improve after launch. Nothing had broken. There was no incident, no page, no outage. The cost had drifted and the quality had drifted, and what gave it away was not a failure but the absence of anyone whose job it was to notice.
That is the seam a monthly contract exists to cover, and it is where research on MLOps maturity (Information and Software Technology, 2025) locates the stall: the gap between delivering a model and sustaining production operations. It also explains why the return on an AI build arrives later than the build does. The productivity J-curve (NBER, 2018) describes exactly this lag, where the value of a general-purpose technology shows up only after the complementary work around it is finished — and that complementary work is the part nobody signed a contract for.
What Ownership Actually Ships
ML LABS engineered the backend of the HeartSciences AI-ECG platform — a medical-device cloud platform that reached clinical production in two countries. AIM Consulting built the frontend, and the cloud AI-ECG platform is the client's core product today. Their Director of Software Engineering put that delivery on the record:
Omar did outstanding work designing and building the backend for our cloud-native AI-ECG platform. I recommend him to any organization needing a skilled and reliable engineering partner.
The build ended. The relationship did not — it became the ongoing engineering retainer that ML LABS runs for HeartSciences today, and that retainer is the reason two further systems exist. Both are published: a claims and billing automation system and a multi-site clinical operations platform, built for the same company under the same standing arrangement.
Look at what those two systems have in common. Neither was a deliverable anyone could have written into a statement of work on the day the platform shipped. They became visible from inside the running system — from knowing which work was still being done by hand on every record instead of on the exceptions, and which of it was safe to automate first. The billing system's phased migration does not promote the automated path to primary processor for a facility until it agrees with expert-adjudicated determinations on 98%+ of records, a gate that exists only because someone was still there to hold it. That is the honest description of what an Operate engagement produces: work you could not have specified when you signed, held to a bar you could.
Ownership Without a Live System
Two situations make the retainer the wrong purchase, and naming them is part of selling it honestly. The first is buying it before anything is in production. Continuous capacity applied to an empty portfolio has nothing to arbitrate between; the engagement fills with discovery that a $750 scoping call or a fixed-price design would have resolved faster and for a fraction of the money. Sequence beats commitment level here — a build, then ownership of what the build produced, is the cheaper path to the same place.
The second is a defined scope that stays defined. One live system, one team, a stable set of priorities — that reader does not need embedded ownership across a portfolio, and should not pay for it. The lower Operate step exists for exactly that shape and costs less than half. And underneath both steps sits a requirement that no contract can supply: one accountable counterpart on your side who can make a decision. Without that, a standing owner has judgment to offer and nobody to offer it to.
First Steps
- List what is already live, and next to each system write the name of the person who gets called when it misbehaves. Blanks in that column are your actual exposure.
- Pull the last three months of inference and infrastructure spend for those systems and ask whether anyone can explain the trend line. If not, that is the drift the monthly contract is priced against.
- Decide which failure you are insuring against — the system not existing, or the system existing unowned — and buy the contract that matches it, not the one that signals more commitment.
Match Contract Shape to Risk
Match the contract to the failure, not to the ambition. If the next move is one nameable system into production against a written acceptance bar, buy the build, take the included Operate window, and let it end cleanly. If the systems are already running, the priorities move faster than a statement of work can be rewritten, and the honest answer to "who owns this" is a shrug, the exposure is ownership and no build will close it.
Where the portfolio is live and the priorities keep moving, an embedded AI engineering retainer puts one operator across all of it: one workstream carried or unblocked each month, a monthly strategy session, async decision support on the architecture and vendor calls, and a written brief every month on what shipped, what is at risk, and what is next. No hiring search, no ramp-up, no context reset between engagements — and cancel with 30 days' notice if the arrangement stops earning its price. The bar a standing owner should be held to is worth setting explicitly before you sign one, and what to demand from a fractional AI owner sets it. Buy the contract that matches the risk you actually carry, and the engagement stops being a subscription and starts being the thing that keeps the system worth having.
References
- Amershi, S., Begel, A., Bird, C., DeLine, R., Gall, H., Kamar, E., Nagappan, N., Nushi, B., & Zimmermann, T. Software Engineering for Machine Learning: A Case Study. ICSE, 2019.
- Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J., & Dennison, D. Hidden Technical Debt in Machine Learning Systems. NeurIPS, 2015.
- Zarour, M., Alzabut, H., & Al-Sarayreh, K. T. MLOps Best Practices, Challenges and Maturity Models: A Systematic Literature Review. Information and Software Technology, 2025.
- Paleyes, Andrei, Raoul-Gabriel Urma, and Neil D. Lawrence. Challenges in Deploying Machine Learning: A Survey of Case Studies. ACM Computing Surveys, 2022.
- Polyzotis, Neoklis, et al. Data Lifecycle Challenges in Production Machine Learning. ACM SIGMOD Record, 2018.
- Brynjolfsson, E., Rock, D., and Syverson, C. The Productivity J-Curve: How Intangibles Complement General Purpose Technologies. NBER Working Paper Series, 2018.
