The system that runs your fixed workflow must belong to somebody. Without an internal product team, which most companies your size lack, that somebody is off your payroll. The pitch appeals: no hiring loop, no ramp, someone who already carried one of these.
The hesitation is also correct, and it is structural rather than a matter of trust. An outside owner who concentrates every decision inside their own head leaves you more fragile than they found you, and you would not find out until they stopped answering the phone. Ownership of the hard decisions concentrates. Everything else, the reasons, the runbooks, the surfaces your team touches without calling anyone, has to spread across your team, or you have bought a single point of failure and given it an impressive title.
This is our product, so read what follows as a bar we are asking to be held to. We have taken more than ten heavy-workload systems to production over fifteen-plus years, across healthcare, telecom, PropTech and finance. We built the backend of a medical-device cloud platform that has reached clinical production in two countries and keeps expanding, and we still run engineering work for HeartSciences, the medical-device company whose cloud ECG backend we built. If whoever owns your system will not meet the bar below, do not sign.
What The Owner Must Decide
Concentration is a scope, not a personality. Three classes of decision get worse when spread across a team under delivery pressure, and those are what you are buying:
- The one-way doors. Where data may live, how records are keyed, what the system may write to, multi-year lock-in. These cost real money to walk back.
- The failure taxonomy. What counts as a failure, what fires when it does, and what terminal state every record ends in. On the inference pipeline behind that ECG backend, every record reaches a terminal state, and that state can be queried.
- What gets removed. Wrappers, hand-built planners, output validators: each answered a real defect, and each distorts once the thing underneath handles it natively.
Which framework, which library, which technique: those are reversible, and the people who live with the consequences should make them. This is checkable before any contract exists: ask a candidate to name your system's one-way doors before seeing your code. Someone who cannot list them from the shape of the business alone has not owned one.
What They Must Never Hoard
The difference between an owner worth hiring and a dependency is an artifact trail, and you can inspect it yourself. Research on how experience becomes knowledge (Organization Science, 2011) draws the line where a buyer should: experience turns into durable capability only when it is retained in people, routines, or artifacts that the organization is able to reuse.
The strongest version of handing capability back is a design decision, not a document. That cloud ECG backend was designed from the start so that onboarding a new organization is configuration, never code: HL7 field mappings, which models are enabled, invoice pricing, storage provisioning. Each of those is a surface the client's own people operate. The multi-site clinical operations and billing automation systems delivered under that engagement are new capability for the same client, not the same integration performed twice.
Ask for the runbook before you ask for the résumé. An owner who cannot show what they left behind on the last system is selling you their calendar, not their judgment.
A runbook states what fires when each failure hits and who does what next. A decision record states why a choice was made, what was rejected, and what evidence would reverse it, so that your team can reopen the decision instead of re-deriving it.
Accountability You Can Check
Everything above stays a promise until it becomes a contract term. Targets are written into the agreement before work starts, and a target only counts if it names the workflow, names the data, and states a pass condition a third party could verify. The scope of ongoing work is written down as a boundary, not described in adjectives, so both sides can tell what is inside it. Response windows are stated as times, not as intent. And changes are quoted as their own engagement, so the work does not silently become whatever was loudest that week.
On ongoing work, what keeps the bar enforced is not a penalty clause. It is a standing obligation to re-earn the work against a client who can walk away on a known date. Ours runs at $10,000 a month, month to month. Anyone asking you for a multi-year commitment on ongoing operation of your system is asking you to pre-pay their retention risk.
Then ask what mechanically blocks a bad release, because "careful review" is not a gate. Our delivery loop runs a builder and a verifier as separate systems across model families, so whatever writes a change is never what certifies it, with deterministic checks that must pass before anything ships. That loop is why separate verifiers are necessary.
| What to demand | How to check it before you sign |
|---|---|
| Targets written before work starts | It names the workflow, the data and a verifiable pass condition |
| A gate before every release | A failing check blocks the release |
| The artifacts, not just the outcome | A runbook, a decision record, configuration your team runs alone |
| A scope boundary and a known exit | Written scope, response times, exclusions, a notice period |
Buy Judgment, Not Hours
Grade whatever you have today against those demands: the internal hire, the agency, the incumbent vendor, or nobody at all. An unowned system does not announce its decay. What ownership of a live system actually buys tells that story with numbers: a client was accumulating unnecessary and polluted data nobody had looked at, and correcting it cut storage costs by more than 60% and made their models 2% better.
What we build runs in a repository we own and transfers to you, code, intellectual property and full history, so leaving is a decision, not a migration project. The work runs in the open in TopDo, and the workspace remains yours. That is what Advisory looks like on a system we built, and the people who sell it should be the same people who do the work.
References
- Argote, L., and Miron-Spektor, E. Organizational Learning: From Experience to Knowledge. Organization Science, 2011.
