Healthcare AI MVP Quotes: Price the Missing Evidence
Two healthcare AI proposals can promise the same screens while buying very different evidence. One may include a verified source corpus, a working retrieval path and a named review process. The other may include a convincing demonstration with those capabilities left for a later phase. Comparing their headline fees before resolving that difference can reward the proposal with the largest omissions.
For a founder or CTO commissioning a medical education product, the first budget decision is what the next payment must prove. This article provides a worked comparison of two fictional bids, a missing-work worksheet and a way to connect spending decisions to accepted evidence. The dollar amounts are illustrative assumptions, not market benchmarks or quotations from real suppliers.
Compare the deliverable before comparing the fee
Start by replacing the phrase healthcare AI MVP with a description of the deliverable. A navigable design, an implemented retrieval workflow and a product evaluated with intended users are different purchases. Each can be useful. Trouble begins when a supplier's proposal uses the same label for all of them and the buyer assumes the most complete version.
Describe the next decision in one sentence. Perhaps the team must choose between an answer-first and a reading-first workflow. Perhaps it needs to establish whether licensed content can support traceable answers. Or perhaps a working system already exists and needs evaluation before a limited release. Those decisions require different work, evidence and reviewers.
The GOV.UK Service Manual states: You should not start building your service in discovery.
Its discovery-phase guidance separates understanding the problem from committing to a service build. Commercial engagements may name their phases differently, but the useful budgeting principle is to make the purpose of each phase explicit.
Write the intended use beside that purpose. A learning tool that explains a licensed handbook is not the same scope as a system that processes patient records or influences an individual treatment decision. Changes to the user, data or intended action should reopen the relevant product and specialist reviews. A budget label cannot settle those questions.
The proposal should also identify what the buyer will receive if the project stops after this phase. Editable files, source inventories, decision records and test definitions can remain useful. Access to a supplier's presentation alone may leave the buyer unable to continue with another team.
Use the case to inspect the boundary between design and proof
Pharos Production's healthcare AI citation UX case shows why source verification belongs in the budget: its reported audit found six of seven demo citations wrong, including four invented references. The team describes checking the source and correcting the design artifacts. Those findings concern that demonstration, not the error rate of a deployed medical AI system.
The account reports 42 elapsed hours of document review, concept design and verification. It explicitly says user testing had not happened, connectors were not live and client choices remained pending. That is a useful design-stage record with stated limits. It is not evidence that a complete healthcare AI product can be delivered in 42 hours.
When reading any case, pair every impressive output with the decision it supports. A reviewable prototype can help a team choose a workflow. It cannot, by itself, establish how a live system behaves when retrieval misses a passage or a user asks an unsupported question. Those remain separate purchases until the proposed work includes them.
The buying question is therefore concrete: which evidence in the case corresponds to work in your quote, and which evidence still needs to be produced? Open the full case alongside the proposal and mark that boundary before asking for a revised price.
Normalize two bids against the same scope
Consider a fictional buyer comparing Proposal A at $44,000 with Proposal B at $59,000. Both promise a source-grounded learning assistant prototype. The buyer's comparison target also requires a verified content map, a bounded live-retrieval check, an evaluation pack and usable handover files. These requirements are assumptions for this example, not a universal minimum package.
Proposal A excludes several of those items. Proposal B includes some and separately prices the rest. The buyer asks each supplier to price the missing work without changing the comparison target. The resulting worksheet is below. All figures are assumed US dollars; taxes, production hosting, content licensing and the buyer's internal labor are excluded at this stage.
| Comparable work | Proposal A | Proposal B |
|---|---|---|
| Initial supplier fee | $44,000 | $59,000 |
| Source verification and content mapping missing from initial fee | $9,000 | Included |
| Bounded retrieval and connector check missing from initial fee | $7,000 | Included |
| Evaluation pack and review preparation missing from initial fee | $5,000 | $4,000 |
| Normalized supplier total | $65,000 | $63,000 |
The initial difference is $15,000 in A's favor. After adding the stated gaps, A totals $65,000 and B totals $63,000. B is $2,000 lower for the assumed comparable scope. No probability, quality score or claim about real supplier performance is hidden in that arithmetic.
The calculation only works if the rows mean the same thing. Content mapping could mean a file list in one bid and verified passage locations in another. An evaluation pack could be a handful of examples or a reviewed set with expected outcomes and retained results. Attach the acceptance evidence to each row before treating it as comparable.
An included label is a coverage claim that still needs verification.
Ask B to point to the deliverable, reviewer and acceptance condition behind each included item. Ask A whether the added work changes dependencies or timing. If the suppliers cannot describe equivalent boundaries, keep the rows unresolved instead of producing a precise-looking total from incompatible inputs.
Price the work hidden inside a citation
A citation marker is a small interface element with several dependencies behind it. Someone must establish the identity and permitted use of the source, preserve its structure during extraction, map the passage to a location a reader can open and determine which claim the passage supports. The proposal should say where those responsibilities sit.
For a handbook-based learning tool, request a small representative sample before estimating the whole corpus. Include ordinary prose and a difficult page, such as a table or a figure with text embedded in the image. The goal is to expose the extraction problem that changes the work estimate. A clean first page cannot stand in for every format in the collection.
Keep source preparation separate from answer generation in the budget. A design team can verify passages for a static demonstration while the production ingestion pipeline remains unbuilt. Conversely, an ingestion pipeline can locate text correctly while the interface makes it difficult for a user to inspect that text. Both gaps deserve named work packages.
Avoid paying twice for an ambiguous source audit. Specify whether the supplier is checking document structure, passage locations, answer support or domain accuracy. The people qualified to perform those checks may differ. Ask what sample was examined, what remains unchecked and what event would require the work to be repeated.
Also establish who supplies the source files and permissions. If a publisher has not approved the intended use, the engineering team may be unable to proceed with that corpus. Record that dependency before booking implementation capacity. Do not silently treat access to a PDF as permission for every proposed use of its content.
Distinguish designed behavior from implemented behavior
A proposal can contain a complete set of interface states without implementing the conditions that select them. A screen for an unsupported question does not prove the system reliably detects unsupported questions. A visible review status does not prove a reviewer has examined the underlying answer. Price the mechanism and its verification separately from the screen.
Use four status labels in the scope register: designed, implemented, evaluated and accepted for the stated use. Each label needs a definition. Designed means the expected interaction exists as an artifact. Implemented means the relevant path runs. Evaluated means someone has examined it against declared cases and criteria. Accepted means the named decision owner has reviewed that evidence within a specified scope.
These are bookkeeping labels, not a certification ladder. An accepted design can still have no implemented retrieval behind it. An evaluated component can still fail its acceptance condition. Store status at the level of a capability rather than assigning one reassuring word to the whole product.
Suppose a demonstration opens a correct passage when the presenter selects a prepared question. The capability might be accepted as an interaction design. A separate work item must establish whether the live retrieval path returns support for other permitted questions, handles absent support and preserves the reference after a source update.
Ask the supplier to mark prepared content and live behavior explicitly in the demonstration. Then use the marked version during commercial review. Otherwise, an observer can carry an assumption from the demo into a contract even though neither party deliberately promised that capability.
Include the buyer's review capacity in the comparison
The supplier fee is only one part of the cost of reaching a decision. A healthcare learning product may need a content owner to approve the corpus, a domain reviewer to assess examples and a product owner to resolve scope conflicts. If those people are unavailable, finished supplier work can wait without becoming accepted work.
Add internal labor as an explicit assumption, even when it is not invoiced to the project. For the fictional comparison, assume A requires 80 buyer-review hours and B requires 40. At an assumed internal allocation rate of $125 per hour, those contributions are $10,000 and $5,000. This rate is a planning input, not a claim about clinical reviewer compensation.
Adding those assumptions to the normalized supplier totals gives $75,000 for A and $68,000 for B. The difference becomes $7,000. That result says what follows from the inputs. It does not establish that B actually needs less review; the buyer must obtain and challenge each supplier's review plan.
Put the scheduling implication beside the hours. A reviewer with four available hours per week cannot complete 40 hours of review in one week. With work available continuously and no other constraint, that allocation takes ten weeks. Parallel review or a narrower scope may shorten the path, but only if qualified capacity exists and the work can be divided sensibly.
Specify whether supplier time continues to accrue while the buyer waits for a decision. A pause clause, a capped support allowance or a reserved review window can produce different economics. Price the actual arrangement instead of assuming that every delay is free or that every calendar day is billable.
Connect each funding decision to an inspectable artifact
Use milestones to define a decision the buyer can make after receiving the work. A milestone called prototype complete is difficult to assess without a boundary. A milestone tied to a source map, a working path and a retained evaluation result is easier to review because the acceptance condition points to something inspectable.
| Work package | Evidence to inspect | Decision it can support | What remains separate |
|---|---|---|---|
| Use-case definition | Intended users, excluded actions and source constraints | Whether the proposed problem is worth investigating | Product performance |
| Source preparation | Versioned inventory and checked passage-location sample | Whether the corpus can support the planned next test | Complete runtime reliability |
| Interaction design | Marked demo with evidence access and failure states | Which workflow to implement or revise | Live retrieval behavior |
| Bounded implementation | Running path with declared inputs and retained outputs | Whether the scoped mechanism works in tested conditions | Broad deployment readiness |
| Evaluation and handover | Cases, results, unresolved issues and accessible files | Fund, narrow, hold or stop the next phase | Clinical or regulatory conclusions outside the review's remit |
Agree what happens when an artifact is delivered but reveals that the next phase should not proceed. Good investigative work can produce a negative answer. Payment terms should distinguish completing the agreed investigation from achieving a desired product result, subject to the actual contract. Do not incentivize the team to hide an inconvenient finding to unlock a milestone.
Avoid using one blended score to approve every row. A polished interaction should not compensate for unavailable source rights, and a functioning retrieval path should not erase an unresolved intended-use question. Record the specific dependency that blocks the next decision, its owner and the evidence needed to close it.
A useful milestone record fits on one page: scope version, delivered artifact, accepted evidence, unresolved items, decision and named owner. Link to the detailed files. The record should explain why money was released without forcing the next reviewer to reconstruct the whole project from meeting notes.
For example, a buyer might accept the source inventory while holding the retrieval implementation because the permitted-use decision remains open. That is partial acceptance of named work, not acceptance of the whole product. The next funding instruction should identify the blocked dependency and the limited activities that can proceed without prejudging it.
A different buyer might narrow the first release to a smaller verified corpus after learning that another source requires substantial preparation. Record what users will lose under that narrower scope and whether the original business problem can still be addressed. Reducing the document count is not a meaningful saving if it removes the content that made the product useful.
Stopping also requires a handover. Preserve the evidence that led to the decision, the source versions examined and the unresolved assumptions. If the business revisits the idea later, it should be able to distinguish a changed constraint from a repeated mistake. Paying for that record can be reasonable even when no further implementation follows.
Keep operating obligations outside the build headline
A prototype budget and an operating budget answer different questions. The first buys a bounded artifact and the evidence needed to decide what comes next. The second pays for keeping an implemented service usable as sources, users and dependencies change. Combining them into an unexplained all-in number obscures both.
Ask what happens when the handbook changes edition. Someone may need to ingest the new file, verify page mapping, review changed passages and test saved references. A source-update screen is only the visible part of that work. Identify the trigger, the owner and whether the supplier's support arrangement includes it.
Separate routine technical operation from content judgment. Hosting, model usage and monitoring can be priced by technical workload. Reviewing an ambiguous source or deciding whether educational wording is appropriate calls for a different responsibility. A support retainer that keeps infrastructure available does not automatically supply that expertise.
For an early estimate, request the billing units and an example workload instead of an unsupported monthly promise. Ask what counts as a request, how retries are handled, what data is retained and which review tasks are manual. The unit may be easy to measure while the number of units remains uncertain.
Do not add an operating allowance to the fictional totals above without stating the period and workload. Those totals compare only the defined next-stage supplier scope and assumed buyer review. A release decision requires a separate operating model once the service scope and intended usage are sufficiently clear.
Test the assumption that could reverse your choice
A comparison is most useful when it exposes which uncertainty changes the decision. In the fictional supplier-only totals, B is ahead by $2,000. An additional B-only requirement costing more than that would reverse the order, assuming A already covers it and every other row stays unchanged. That is a reason to inspect coverage carefully, not a reason to prefer one proposal automatically.
Suppose B later excludes a $6,000 handover requirement that A includes. B's normalized supplier total becomes $69,000, compared with A's $65,000. After retaining the assumed internal review costs, however, B totals $74,000 and A totals $75,000. The supplier ranking reverses while the combined comparison still favors B by $1,000.
This example shows why the comparison basis must travel with the number. A buyer looking only at supplier invoices can reach a different conclusion from a buyer including internal review capacity. Neither total establishes quality. Both are incomplete if the handover requirement itself is poorly specified.
Change one assumption at a time. Review hours, paid waiting and excluded source work are reasonable candidates when the proposals leave them uncertain. Do not assign invented probabilities to make the worksheet appear more scientific. If a range is available, identify who supplied it and what would make the high end occur.
Keep unknowns visible. An unpriced dependency is not zero cost, but an arbitrary contingency is not evidence either. Ask for a bounded investigation or a separately priced option. If the unknown can invalidate the product, resolve it before committing to the phase that depends on it.
Make handover cost concrete before comparing it. Ask whether another authorized team can open the design files, identify sample records, reproduce the documented checks and understand which materials require separate permission. Exported screenshots may preserve appearance while losing the relationships needed for continued work. Price the actual transfer of usable artifacts, together with a bounded walkthrough and a route for clarifying omissions.
This does not require unlimited post-project support. It requires a defined handover boundary that both suppliers can price and the buyer can inspect.
Make the next supplier conversation specific
Bring a short comparison brief to the next meeting. Name the intended user and the decision the next phase must enable. Identify the corpus you control, the behavior already implemented and the assumptions still represented by prepared content. List the artifacts your team must own when the engagement ends.
Ask the supplier to return the same worksheet with each row marked included, excluded or unresolved. An included row needs a deliverable and acceptance condition. An excluded row needs a separate price or an explicit decision to leave it outside the comparison. An unresolved row needs an owner and a practical way to reduce the uncertainty.
Then ask who will review the work on your side. A proposal that requires a specialist you cannot make available is not ready to start on the assumed schedule. Resolve that constraint before using a delivery date in a board presentation or a customer commitment.
Use Pharos Production's aesthetic-medicine AI discovery and citation UX case as the companion evidence review. Compare its documented artifacts and unfinished work with the promises in your own proposal. If you are planning a source-grounded learning product, take your intended use, source inventory and unresolved budget rows into the project-estimate conversation linked from that case.
The next commitment should name the evidence it buys and the decision that evidence enables. A smaller phase can be worthwhile when it resolves the assumption blocking a larger one. Record the remaining uncertainty alongside the accepted work so the next team inherits an honest starting point.
Evidence notes
Sources reviewed on : the linked Pharos Production healthcare design case and GOV.UK Service Manual discovery guidance. Case figures are attributed to the published design-stage account, dated September 24, 2026. The quote worksheet, review-hour assumptions and handover sensitivity are original hypothetical examples, not supplier offers, market averages or measured project outcomes. This article addresses software procurement for an educational product; it makes no clinical performance or regulatory classification claim.
Comments
Post a Comment