What a vendor needs before estimating a healthcare device app in 2026

TL;DR

What a vendor needs before an estimate on a device or healthcare build is a short list, and in 2026 it is the same five items: SDK access, an API specification, a physical prototype, a device list and wireframes covering every user role. Miss them and the number you get back is a guess wearing a spreadsheet.

• Generic discovery checklists stop at process artifacts. None of them tell you which handset the SDK supports.
• A mockup set covering 7 screens of a 30 to 60 screen clinical product prices roughly a tenth of the work.
• Since February 2, 2026 the quality records a US device reviewer expects follow ISO 13485 clauses, and design inputs are one of them.
• In around a quarter of the healthcare and device requests on our file, something had to be asked for before the work could be priced at all.

Why an estimate without inputs is a guess

An estimate is a model of work nobody has done yet. For a web product the unknowns sit in your backlog, uncomfortable but visible. For a product attached to hardware they sit inside somebody else's firmware, and staring at your feature list will not surface them.

What a vendor prices on a device project is the integration surface: how the app talks to the thing, how often, through which radio, under which permission model, and what happens when the connection drops in a corridor. Screens are the cheap half.

The expensive half stays invisible until someone opens a debugger. On Fitbit, early Android handsets had no Bluetooth 4.0 at all, and our team spent two months deciphering Samsung's proprietary technology before a tracker could sync with a phone. Nobody writes two months into a proposal from a product brief. You find it once the radio and the firmware are on a desk.

So read a very wide range as a confession. The width measures what the vendor was not given.

When the estimates you already hold disagree, our guide to the software development timeline estimate shows how to read the gap between them.

The February 2026 rule change moved the bar

On February 2, 2026 the FDA's Quality Management System Regulation took effect, amending 21 CFR Part 820 to incorporate ISO 13485:2016 by reference. For software that means inspections follow the clause structure European notified bodies already use, and design inputs stop being a conversation and become a record with a version on it.

Two companion documents say the same thing from the submission side. FDA guidance on the content of premarket submissions for device software functions sets out the documentation a software device carries, scaled by risk rather than by screen count. The cybersecurity guidance finalized in February 2026 expects a software bill of materials, an itemized list of every third-party component in the build, vendor SDK included.

Which is the practical point. The artifacts a competent vendor asks for before quoting are the artifacts a reviewer asks for after launch, so assembling them early is not a tax. Skipping them is.

How we built this checklist

Three rules, applied to everything below.

• Regulatory facts come from the instrument, not from a summary of it.
• Engineering examples come from work we published as case studies, with the page linked so you can check the claim.
• Where we publish our own numbers, any group with fewer than three data points is not published.

The list comes from intake notes: the things we had to ask for before a price could be attached to a healthcare or device request.

One disclosure. Mercury Development builds device connected and healthcare software, so every engineering example here is our own work. Generic versions of this checklist exist. Jaspero publishes five discovery artifacts it hands over before a contract: an entity and event model, an integration inventory, a must ship first list, a non goals list and an assumptions register. Useful, and entirely silent on which Android build your tablet is running.

The five inputs at a glance

Four of the five are documents. One is a box that has to be couriered, and the box is the one that slips.

SDK access, and what the SDK actually supports

"There is an SDK" is not an answer. The question is which operating system versions it supports, which handsets it was tested on, which language bindings ship with it, what the license permits, and whether a working sample app comes with it.

We have been on the thin end of that answer. For Kensington Proximo, Android had no built-in Bluetooth Low Energy support yet, so the only route was a proprietary SDK from Samsung that supported exactly one device, the then unreleased Galaxy S4, and shipped as a partially unstable pre-release beta. The team delivered a fully functional Android app in three months. Read that number with its constraint attached: one supported handset, beta tooling.

An SDK carries a paperwork consequence too. IEC 62304 treats anything you did not develop under a compliant process as software of unknown provenance, and every such item gets named, versioned and analyzed for failure. That is the same list the cybersecurity guidance wants in your software bill of materials, so the SDK question and the submission question have one answer.

If the SDK sits under an NDA, send the NDA first.

The SDK bindings also narrow the stack choice, which we compare in React Native vs Flutter vs native for BLE apps.

An API specification beats an API promise

A specification is six things: the endpoint list, the authentication model, the payload schema, the error codes, the rate limits and a sandbox with credentials that work. A Postman collection someone exported last year is a start. A sentence saying the API exists is not an input.

Rate limits deserve their own line because they change architecture rather than effort. If a data source refuses more than a few calls per interval, your app cannot poll on demand, and you are now building a sync service with a cache and a staleness indicator. That is a different product from the one on your roadmap.

Error codes do similar work. The interesting requirement in connected health is rarely the happy path. It is what the screen shows when the reading is forty minutes old and somebody is about to make a decision with it.

Where the API is yours and still moving, say so. An interface that changes under the build moves budget and schedule for reasons nobody can price in advance, and a vendor who knows will phase the integration instead of fixing it to a date.

A physical prototype beats a rendering

Hardware behaves. Renderings do not.

On ORIGOSafeDriver, a monitoring system for commercial fleets, the manufacturer's modem driver turned out to be unstable and we wrote our own. We debugged Bluetooth Low Energy to stop disconnections, cut data traffic to 8 MB per device per month, and fixed a power fault that had been draining a vehicle battery in three days. None of those four items is visible in a datasheet or a pitch deck. They are visible with the device on a desk.

Ask for two units rather than one, because half of pairing work is about what happens when a second device is in range. Ask for the firmware version to be written on the unit, because "which build was that" arrives within a week. Ask for the charging kit, since a flat prototype is an absent prototype.

If the hardware does not exist yet, that is a legitimate project state and a vendor should still talk to you. What changes is the shape of the engagement.

What the prototype then has to survive in BLE testing is covered in our guide to medical device companion app development.

The device list is really an OS version list

Buyers hear "device list" and picture a product catalogue. Engineers mean the handsets, tablets and panels your software has to run on, with OS versions attached, plus locales and carriers where either affects the build.

The list prices the test matrix, which is the part of a quote people argue with and the hardest part to compress. Bluetooth makes it worse. On Kensington PresentAir we shipped the same remote control feature set across iOS, Android and Windows phone, and the case study is blunt that integrating the radio on each platform took significant effort because of platform characteristics and limitations. Same chip, different stacks, three sets of edge cases.

One line in the list can also decide a licensing question. Apple's MFi program does not apply to accessories that connect using only Bluetooth Low Energy, Core Bluetooth or standard Bluetooth profiles supported by iOS. Move outside that set and you are into a licensing program with its own timeline.

Wireframes cover roles before they cover screens

This is where estimates break most often, and most quietly.

A multi-role clinical product tends to land between 30 and 60 screens once a patient view, a clinician view, a scheduler, an administrator and some form of audit trail all exist. A mockup set covering 7 of them is not a sample. It prices roughly a tenth of the product, and the missing nine tenths are weighted toward the screens nobody demos: user management, consent records, export, retention settings, the audit log.

Our own delivery process puts user flows, wireframes and mockups inside the analysis and design step that precedes development, which is why the gap shows up at pricing time rather than later.

You do not need pixels and you do not need a designer. You need a screen inventory per role: list every role that will log in, then list the screens each one needs to finish its job. Three columns in a spreadsheet beats a beautiful prototype of the patient app alone.

Administrator screens are where regulated requirements become code. Credential issuing, permission levels, report configuration and backup settings are not polish items.

In a monitoring program the role list maps to four separate surfaces, as our breakdown of remote patient monitoring architecture shows.

What to send when you do not have all five

Almost nobody has all five. Send what you have, in this order, and name the gaps instead of hiding them.

1. A one paragraph intended use statement. It decides regulatory status, and regulatory status decides the evidence budget.
2. A one page integration diagram. Boxes and arrows beat prose for showing what talks to what.
3. Whatever protocol material exists, including drafts and engineer notes. Draft documentation is still documentation.
4. A recorded walkthrough of the current product or the bench setup. Ten minutes of screen capture replaces an hour of meetings.
5. A role list with the top three tasks per role, even without a single wireframe.
6. A named owner and a date for each missing item.

The last line is the one buyers skip and the one that moves fastest. A missing artifact with an owner and a date is a schedule. A missing artifact without them is a risk premium, and it reaches your number whether or not anyone says so out loud.

What our own intake record shows

Counted by hand across our healthcare and connected device requirement records, in around 25% of requests the material that arrived was not enough to attach a price without asking for something first. Those requests were not unserious. Several became contracts. They simply arrived before their inputs did.

Inside that group the gaps sort into categories.

• Around 45% were technical input gaps: no SDK, no API specification, no device list or protocol documentation, or an interface still changing under us.
• Around 35% were definition gaps: screens covering part of the product, roles with no flows, or no approved backlog to build from.

A third category, access to an existing system or its code, had fewer than three data points, so it is not published here. Same rule as every figure above.

One pattern matters more than the percentages. The gap that costs most is rarely the one buyers apologize for. People apologize for rough wireframes and stay quiet about an undocumented radio protocol, when the wireframes cost a week of analysis and the protocol cost us two months on a tracker sync.

Why we price a range instead of refusing

Opinion, stated plainly. Refusing to quote until every artifact lands is a defensible engineering position and a useless commercial one, because you have a board meeting and the hardware ships when it ships.

We split the number instead. The part that does not depend on the device gets a normal band: accounts, onboarding, the administrator console, reporting, the clinical workflow that is only software. The device layer gets its own line with the dependency written next to it and a short bench phase attached, whose single deliverable is replacing that line with a measured figure.

Two honest limits. Having all five artifacts does not make an estimate correct. It makes it falsifiable, which is a smaller claim and a more useful one, because you can point at the assumption that failed. And no checklist compresses protocol work: the schedule risk sits in the radio and the firmware, and these artifacts move it from surprise to plan rather than removing it.

Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The intake reviews behind this checklist, where incoming device requests are read for SDK coverage, interface documentation and platform constraints, come from the engineering practice he works in.

Send us what you have and we will name what is missing

Send your intended use statement, whatever interface material exists and a list of the roles who will log in. We will come back with the parts we can price now, the parts that depend on your hardware, and the shortest route to closing the gap between them.