The Health-Tech Agency Bake-Off: 9 Vendor Questions a Diagnostics Founder Asked Us, and the 4 We'd Answer Differently Six Years On

Why a health-tech agency bake-off is not a normal agency pitch

A health-tech agency selection differs from a normal agency pitch because the buyer is not really buying screens. They are buying a party who will hold personal health data, touch a laboratory workflow, and still be reachable in year four when a regulator, a clinician, or a customer asks how a result was produced.

In 2019 GlycanAge was preparing to sell a biological age test built on glycan analysis: physical kits shipped to customers, samples returned to a laboratory, analysis run on instruments, and a result released back to the customer. That chain crosses consent capture, chain of custody, cross-border shipping, laboratory information management, payment, and clinician review. Almost every question we were asked was about the seams between those things, not about the things themselves.

What follows is the substance of that evaluation. We have grouped the nine questions into the three areas they actually clustered into, given the answer we gave at the time, and marked the four where six years of running the systems proved our answer incomplete. If you are a founder running your own bake-off, the questions are more useful than our answers. Ask them of every shortlisted agency and compare the shape of the hesitation.

Questions 1 to 3: ownership, exit, and who holds the data

The first cluster was about what happens if the relationship ends. A founder in diagnostics cannot afford a vendor who becomes a single point of failure for regulated data, so the ownership and exit questions came before anything technical. All three should be answerable in writing before a contract is signed, not after.

Our answers in 2019 were: the client owns all code and all repositories from the first commit, with our accounts as collaborators rather than owners; all cloud infrastructure and data storage lives in accounts the client owns and pays for directly, so there is no vendor-held database to extract; and handover means transferring collaborator rights, documented runbooks, and environment access, not a migration project. Those answers have held up unchanged. We still give them, and we still put them in the contract rather than in a deck.

The one thing we underestimated was operational knowledge rather than code. Six years of decisions about why a result state machine has a particular gate, or why a kit status cannot be skipped, do not live in a repository unless someone deliberately writes them down. We now treat decision records as a deliverable rather than a courtesy, because that, not the source code, is the thing a successor team actually needs.

• • Q1: Who owns the code, the repositories, and the CI configuration from day one?
• • Q2: If we terminate, what do you hold that we cannot immediately access ourselves?
• • Q3: Whose cloud accounts hold sample data, customer records, and backups, and whose payment method is on them?

Questions 4 to 6: the LIMS boundary, liability for a bad result, and the DPA

The second cluster was about the laboratory boundary and legal exposure. These are the questions where agencies without regulated experience give away that they have none, usually by answering too fast. The honest answers involve drawing a line and saying clearly what is on the other side of it.

Question 4 was who owns the LIMS integration. Our answer was that we own the integration surface, meaning the contract, the queueing, the retries, the reconciliation, and the audit log of every exchange, but we do not own instrument output correctness or the laboratory's internal validation. That split has held. Question 5 was whether we carry liability for a mis-released result. Our answer was that we carry liability for defects in software we wrote, under the professional indemnity terms of the contract, but that clinical responsibility for a released result sits with the qualified person who releases it, and that the correct engineering response is to make release impossible without a recorded human decision. Question 6 was whether we would sign a Data Processing Agreement as processor. We said yes, and we did, with named sub-processors and a documented breach notification path.

The naive part was question 5. In 2019 we framed liability as a contractual allocation. What we did not appreciate is that the interesting failure mode is not a wrong number, it is a right number released to the wrong person, at the wrong time, or without the consent state that permitted it. Those are engineering problems, and they meant building release gating, consent versioning, and immutable audit trails as first-class product features rather than compliance overhead bolted on later.

• • Q4: Where does your responsibility for the LIMS integration start and stop?
• • Q5: Who carries liability if a result is released incorrectly, and what does your software do to prevent it?
• • Q6: Will you sign a DPA as a processor, name your sub-processors, and commit to a breach notification window?

Questions 7 to 9: on-call, response times, and continuity of the team

The third cluster was about operations. A laboratory that runs on weekdays cannot wait until Monday for a broken sample intake, and a founder evaluating agencies should ask exactly who picks up the phone, at what hour, and what happens when that person leaves. Vague answers here are the strongest negative signal in a bake-off.

We answered that named engineers, not a rotating pool, would be assigned to the account, that we would be reachable during laboratory operating hours with an escalation path outside them, and that we would keep at least two people familiar with every critical system so no single departure stalls the lab. Six years later the named-team commitment is the part that has mattered most. Continuity is why the systems still fit each other rather than accumulating six generations of unrelated conventions.

Where we were naive was the definition of an incident. In 2019 we thought in terms of uptime: is the portal up, is the API responding. In practice the incidents that hurt were silent ones. A batch of kit statuses that stopped syncing and nobody noticed for a day. A courier webhook that quietly changed its payload shape. We now instrument business events rather than only infrastructure, and we treat a stalled queue as an alertable condition in its own right.

• • Q7: Who specifically is on call when the lab is running, and how do we reach them?
• • Q8: What is your response commitment for something that blocks sample processing versus something cosmetic?
• • Q9: How many people on your side understand each critical system, and what happens if one of them leaves?

The four answers we would give differently in 2025

Four of our 2019 answers were not wrong so much as under-scoped. Each became bigger than we described once the product met real regulation, real logistics, and real clinicians. If you are asking these questions of an agency today, these are the four where you should push for more than a confident yes.

First, regulatory labeling. We treated IVDR-era labeling and claims as a content problem, something the client would supply and we would render. It is a versioned data problem. Labels, intended-use text, and the version of the report template attached to a specific released result all need to be recorded against that result, because the question later is not what the label says today, it is what it said on the day this customer got their number. We would now answer with a versioning model rather than a CMS.

Second, clinician-gated release. We originally scoped review as an approval button. It became a workflow with queues, reassignment, partial holds, re-review after a re-run, and a full record of who saw what and when. Third, cross-border kit shipping. We described this as courier API integration. It is customs documentation, country-specific eligibility rules, and stock allocation across warehouses, and the software has to refuse orders it cannot lawfully fulfil. Fourth, deletion. We said we could delete a customer's data on request. The correct answer is that deletion in diagnostics is selective: identity data is erasable, but certain records tied to a released diagnostic result and its audit trail are subject to retention obligations, and the system has to distinguish those two categories at the schema level, not at the point somebody files the request.

• • Regulatory labeling: a versioned artifact bound to each released result, not editable site content.
• • Clinician-gated release: a queue and audit workflow, not an approval button.
• • Cross-border kit shipping: eligibility and customs rules that can block an order, not just a courier API.
• • Data deletion: a schema-level split between erasable identity data and retained result records.

How to score the agencies in your own bake-off

Score agencies on the specificity of the answer, not the confidence of it. For each of the nine questions, ask for an example from a system they actually shipped, a named artifact you can review, and the boundary they refuse to cross. An agency with regulated experience will happily tell you what they are not responsible for.

A practical scoring approach: give two points where the agency can point to a concrete implementation they have run in production, one point where they can describe a credible plan, and zero where they answer in adjectives. Weight the ownership and exit cluster highest, because those are the answers you cannot renegotiate later from a weak position. Then, separately, check the answers against the four areas above and see whether anyone volunteers the harder version of the question before you raise it.

One last suggestion from the vendor side of the table. Ask each shortlisted agency what they got wrong on their last long engagement. If nobody can name anything, they either have not run a system long enough to find out, or they are not going to tell you when it happens on yours.

The engagement these questions came from is documented in our GlycanAge case study, covering the 10+ interconnected systems we have built and maintained over six years.