There is no useful price without a milestone
An estimate for a guided capture prototype cannot be compared directly with one for an application that includes cloud processing, hospital integration and ongoing support. Even similar screens can sit on top of very different delivery work.
We estimate around the first useful milestone and the uncertainty it needs to resolve. This guide explains the questions behind that estimate. It does not set a fixed price or a delivery promise for an unspecified product.
Separate the proof of concept from the next release
A proof of concept might test whether a workflow is usable on a tablet or whether a hospital interface accepts a report. Agree on its test environment, inputs and acceptance criteria.
Also ask what the prototype leaves out. Production infrastructure, broader device coverage, release evidence and operational support may require additional work. A successful demonstration should not quietly become a claim that those stages are complete.
In our clinical-report delivery engagement, an automated development run against a simulated EHR established a defined integration milestone. Staging preparation and release records were separate parts of the contribution. That distinction makes the remaining work easier to discuss and budget.
Look beyond the number of screens
Supported platforms change the work. A phone-and-tablet product across iOS and Android needs design decisions and verification on the agreed devices, including behaviour that differs between platforms.
Camera workflows are one example. In our mobile AI product work, the application needed to handle capture orientation, upload recovery and the transition from processing to a result. Those behaviours matter even when the screen layout looks simple.
Ask what happens outside the happy path. Permission failures, interrupted uploads and unavailable services need a defined response. The estimate should make clear which conditions will be implemented and tested.
Integration estimates depend on access and confirmation
Connecting to a clinical system involves more than adding an API call. The team needs to understand the receiving system’s contract, map the required information and agree what counts as a successful delivery.
Sandbox access, test fixtures and third-party review can affect the schedule. Confirmation, retries and a delivery history can change the implementation scope. Ask which dependencies are available now, which are assumptions and who is responsible for resolving them.
Our EHR integration guide explains the distinction between sending a report and knowing what happened to it.
Include verification and release evidence
Agree how the engineering work will fit your quality system. The budget may need to cover requirements, design reviews, verification tooling and release records, along with time to address reviewer feedback.
Regulatory strategy, clinical validation and submission support need named owners and their own scope. Do not assume they are included because a proposal describes medical software experience. Our partner-selection guide includes questions for checking those responsibilities.
Plan for the costs after implementation
Separate development fees from cloud operation, external platform charges and support. Ask who monitors the application, investigates an incident and prepares an update when a supported platform changes.
Handover also needs a scope. Repository access, deployment instructions and known issues make a different starting point from a demonstration alone. Agree on the environments and documentation your team will receive.
Ask for an estimate you can examine
A useful proposal should let you identify:
- What the first phase delivers and how it will be accepted.
- Which assumptions could change the price or schedule.
- What your team must supply and when it is needed.
- Which verification and quality records are included.
- External costs, exclusions and support arrangements.
- How changes will be estimated before additional work begins.
If a dependency is uncertain, ask for an initial investigation or a range tied to explicit assumptions. Avoid treating an unexplored integration as a fixed implementation task.
You do not need a finished specification to start. Share your product stage, existing assets and next milestone. We can shape a medical software development engagement around what needs to be learned and delivered first.