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. 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 yourself against.
A build is insurance against the system not existing. A monthly engagement 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, whose platform has reached clinical production in two countries and keeps expanding, and it runs an ongoing engineering retainer for that company today. Delivery first, then ownership: that sequence is the history of that engagement.
Three Tests Before You Sign
- The output test. Can you write down the deliverable in a single sentence, and would a stranger who read it know when the work has been completed?
- The continuity test. Will the next three decisions depend on the context of the first one?
- The portfolio test. Is it one system to watch, or several to arbitrate between?
Pass only the first test and you are buying a build. Pass the second and the third tests and you are buying ownership. If you pass none of them, no contract is going to save you, because the thing that is being bought has not yet been decided upon.
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
Product buys a defined system for one fixed price, with scope, releases and payment milestones agreed before work begins, run by the person who built it. Then it ends.
Advisory is priced monthly because what it buys does not end. At $10K/mo it puts an accountable owner on what we built: monitoring, drift and cost review, incident triage, and a monthly written brief on what ran, what changed, and what is at risk. It deliberately does not buy code. New features, enhancements and roadmap work are their own engagement, quoted separately, and there is no monthly allowance for changes; the boundary keeps the price honest and the work bounded. Month to month: either party ends it with 30 days' notice, no lock-in. The guarantee is on the work, not 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 a production ML system; the rest is configuration, data plumbing, monitoring, and glue, and all of it has an owner or it has an entropy budget. 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. Failures stop being loud, because loud failures get caught before launch; what survives into production is the class that returns a plausible wrong answer.
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 is in the case for systems that improve after launch. Nothing had broken. There was no incident, no page, no outage. What gave it away was not a failure but the absence of anyone whose job it was to notice.
What Ownership Actually Ships
ML LABS engineered the backend of the HeartSciences cloud AI-ECG platform, 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 became the ongoing engineering retainer that ML LABS runs for HeartSciences today, and that retainer is the reason two further systems exist: a claims and billing automation system and a multi-site clinical operations platform.
Neither one was a deliverable anyone could have written into a statement of work. They became visible from inside the running system. 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 what an Engineering engagement produces: work you could not have specified when you signed, held to a bar you could specify.
Ownership Without a Live System
Two situations make Engineering the wrong purchase. The first is a nameable system with nothing in production. Product, then Advisory to run it, reaches the same place.
The second is a defined scope that stays defined: one live system, one team, a stable set of priorities. That is exactly the shape Advisory is built for. Underneath it 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.
Match Contract Shape to Risk
Match the contract to the failure, not to the size of the ambition. If the next move is one system that can be named into production against a written acceptance bar, buy the build, and let it end cleanly. If the systems are already running and the answer to "who owns this" is a shrug, the exposure is one of ownership, and no build is going to close it.
Where we built it and nobody owns it, Advisory, at $10,000 a month, puts one accountable person on keeping it working: monitoring, incident triage, a standing review of cost and drift, and a written brief every month. The bar a standing owner should be held to is worth setting before you sign, and what to demand from a fractional AI owner sets it.
References
- 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.
