Choosing a healthcare software development company comes down to nine checks, and most of them happen before anyone talks about features: where protected health information lives, who signs the business associate agreements, how patient data reaches AI models, whether the team has shipped integrations with the EHR and practice management systems your users already run, and whether the engineers on the sales call are the ones who will still be on the account in year three. The best healthcare software development companies pass all nine without hesitation. This guide lists the checks, the red flags, and the questions to ask in a 30-minute call, drawn from building RiseMD, WinitClinic and other HIPAA-regulated products.
Start with the data, not the feature list
Most vendor evaluations open with a feature list and a budget. In healthcare the first question is different: which parts of the product touch protected health information (PHI), and which do not. A booking screen that stores a name and a date of birth is inside the HIPAA boundary. A marketing site is not. A payment record that knows an amount and a customer is outside the boundary only if it never learns a diagnosis.
A vendor who has done this before will ask for a PHI inventory in the first call, or will draw one with you on a whiteboard. That inventory decides the architecture: which cloud services need a business associate agreement (BAA), which third parties can be used at all, where encryption and audit logging are mandatory, and how much of the system can be built with ordinary tooling. Get it wrong and every later decision costs more. The HHS Security Rule overview is the reference your vendor should already know.
Check 1. They can draw the HIPAA boundary on day one
Ask the vendor to sketch the BAA chain for your product: cloud infrastructure, messaging, video, email, analytics, error tracking, customer support tooling. Every service that stores, processes or transmits PHI needs a BAA, and HHS is explicit that a business associate is responsible for its own subcontractors.
The useful signal is what the vendor does with services that will not sign a BAA. Stripe, for example, does not sign one. On WinitClinic, a functional medicine marketplace with video consultations and at-home lab testing, that meant designing payments so that protected health information never enters payment metadata at all, while messaging and video ran on Twilio under a BAA. A team that has solved this once will describe the pattern in two sentences. A team that has not will say "we are HIPAA compliant" and move on.
Check 2. Ask exactly how PHI reaches AI models
Every healthcare product now has an AI feature on the roadmap: call transcription, intake summaries, coding assistance, patient messaging. The question that separates vendors is where the model runs and what it sees.
Raw PHI sent to a public LLM endpoint without a BAA is a reportable problem, not a shortcut. The alternatives are a BAA-covered model offering inside your cloud boundary, de-identification before the call, or a custom model on HIPAA-eligible infrastructure. On RiseMD, a healthcare marketing platform used by more than 5,000 dental practices, inbound patient calls are recorded, transcribed and graded by an AI system that runs entirely inside the HIPAA boundary; grading is fully automated, and every score carries the transcript evidence behind it so a practice manager can dispute a grade and see why it was given.
Ask for that level of detail: which model, where it runs, which BAA covers it, how outputs are logged, and how a wrong answer can be traced back. Our generative AI development page describes the evaluation and guardrail work that goes with it.
Check 3. Integration experience with the systems your users already run
Healthcare products rarely stand alone. They read and write practice management systems, EHRs, labs, call tracking, payment processors and scheduling tools, through HL7, FHIR, vendor APIs and sometimes flat-file exports. Ask which specific systems the vendor has integrated with and what broke.
The second question matters more than the first. Integrations fail quietly: a practice management system changes an API, a lab renames a field, a call tracking provider deprecates a webhook. On RiseMD, marketing attribution is only real because it ends at the practice's production ledger, so a change in the practice management integration shows up as a wrong revenue number if nobody is watching. A vendor who has run an integration for years can tell you how they noticed the last break before the client did.
Check 4. Credentialing and state rules if practitioners are involved
Marketplaces and telehealth products add a layer that pure software teams miss: the rules about who may see which patient. Practitioner onboarding needs NPI lookup, state licensure checks and board certification where applicable, and cross-state telehealth rules decide which practitioners a patient in a given state is allowed to book.
This is domain logic, not a library you install. Ask whether the vendor has built credential verification and state-based matching before, and how they keep the rules current when a state changes them. WinitClinic's practitioner discovery runs on exactly this logic across more than 1,000 practitioners.
Check 5. Team continuity: who is on the account in year three
The engineers who learned your compliance setup, your integrations and your edge cases are the asset. Ask three questions: what is the average tenure of an engineer on a client account, what happens when an engineer leaves, and can you speak to a client who is in year three or later.
Industry practice at offshore shops and talent marketplaces is to rotate people between accounts, which means the knowledge walks out with them. Look for a written replacement commitment with a time limit, references from long engagements, and a model where you interview every engineer before they start. At EltexSoft the average client engagement is 3.4 years, the engineer who scoped the work is the one who builds it, and replacement within two weeks is written into the contract; the how we work page has the details.
Check 6. Security controls you can audit, not a badge
HIPAA has no official certification, so "HIPAA certified" on a vendor's site is a marketing phrase. What you can verify is controls: encryption in transit and at rest, multi-factor authentication for anyone who touches ePHI, tamper-evident audit logs for every PHI access event, least-privilege access reviews, an incident response plan, and a BAA signed by the vendor itself since the vendor's engineers will see PHI.
Ask to see the controls on an existing project rather than a slide. SOC 2 reports and HITRUST certification are useful when your buyers demand them, but they describe the vendor's organization, not your product's architecture. The architecture is what you are paying for.
Check 7. Pricing model and what the rate includes
Senior engineers at nearshore and Eastern European studios run $50 to $99 per hour; US agencies commonly charge $150 to $250 for comparable seniority. The number that matters is what the rate includes: QA, DevOps, a technical lead, project management, and the compliance work itself. A low rate that excludes QA and infrastructure is not low.
Prefer month-to-month retainers over 6 or 12-month minimums, and ask for published rates. A HIPAA-regulated product usually lands above the $40K to $100K that a generic MVP costs, because the BAA chain, audit logging and access controls are scope, not overhead, and they have to exist before the first patient record is stored.
Check 8. Proof: numbers, named clients and a reachable reference
Any of the best healthcare software development companies will have case studies with the architecture, the compliance setup and the results. Look for numbers a client has published, not numbers the vendor estimates. RiseMD reports $3.2M in new patient production from $160K in marketing spend; WinitClinic handles more than 10,000 consultations a month. Then ask for a verified review platform profile and a reference call.
One more test: ask who will be on the first technical call. If it is a salesperson rather than an engineer who will do the work, the proof you were shown may belong to a different team.
Check 9. Contract terms: IP, exit and data handover
Three clauses decide how safe you are if the relationship ends: work-for-hire with the client owning all code and infrastructure accounts from day one, a documented handover procedure including the PHI stored in any vendor-controlled system, and a BAA that spells out data return or destruction. Add a clause that the vendor cannot reuse your PHI, de-identified or not, for anything else.
Red flags
- "HIPAA certified" or "HIPAA compliant hosting" as the whole compliance answer.
- No PHI inventory question in the first conversation.
- Public LLM APIs in the architecture with no BAA and no de-identification step.
- Case studies without numbers, client names or a reachable reference.
- A sales engineer on the discovery call who will not be on the project.
- A 12-month minimum before any code is written.
- No written replacement commitment when an engineer leaves.
- Payment, analytics or support tools that will see PHI and have no BAA.
A 30-minute call script
- Which parts of our product do you think touch PHI, based on what I just described?
- Walk me through the BAA chain you would propose, service by service.
- Where would our AI feature run, and what would the model see?
- Which practice management, EHR or lab systems have you integrated with, and what broke?
- Who on this call will write code on our project, and for how long have they been on their current account?
- What is your rate, what does it include, and what is the minimum term?
- Which client of yours is in year three or later, and can I speak to them?
- What happens to our data and code if we stop in month six?
Where EltexSoft fits
We are a Los Angeles software engineering studio founded in 2015, with 35 to 50 senior engineers and no juniors on client projects. Our healthcare work includes RiseMD, WinitClinic and MOTTIV, built under BAA chains on HIPAA-eligible infrastructure; the healthcare app development and medical software development pages list the scope. Rates are $50 to $99 per hour on a month-to-month retainer, and the first call is with an engineer. If you are shortlisting, we are one of the teams worth 30 minutes. For the general version of this framework, see how to choose a software development partner.