How to choose a HIPAA-compliant software development company
Choose a HIPAA-compliant software development company or partner by testing four things: proof they have taken healthcare products to production, security practices you can inspect, how they handle PHI inside their own tools and BAAs, and how they run a project day to day. Ask the seven questions below and score the answers. A partner who answers specifically and shows evidence is worth a closer look. One who answers with slogans is not.
The stakes are higher than a normal software hire. A 2025 report from Bessemer Venture Partners, AWS and Bain, based on more than 400 payer, provider and pharma leaders, found that just 30% of AI pilots had reached the production stage (Healthcare Dive coverage). Moving from pilot to production takes engineering, security and integration work that is easy to leave out of the original plan. The right partner plans for that from the first week.
Seven questions to ask any HIPAA development partner
1. Have you taken a healthcare product from pilot to production, and can I speak to that client?
A demo or prototype shows design skill. A live product with real users shows that the team can handle security reviews, integrations and support after launch. Ask for a reference you can call. If client names are confidential, ask for a description of the product, the users and what went live.
2. How do you handle PHI in your own environment?
A partner's own practices matter as much as the code they write. Ask whether developers ever see real patient data, how test data is created, who has access to production, and how laptops, tickets and chat tools are kept free of PHI. The best answer is that developers work with de-identified or synthetic data by default and production access is limited and logged.
3. Will you sign a BAA, and which of your vendors are covered?
If the partner will touch PHI, it needs a BAA with you, and any subcontractor it uses needs one with the partner. Ask for the list of vendors involved. Our guide to the Business Associate Agreement for app developers explains what the contract must cover.
4. What does your default security architecture look like?
Listen for specifics: encryption in transit and at rest, role-based access, audit logging, isolated PHI storage, tested backups. Our guide to HIPAA-compliant backend architecture lists the six controls we look for. Ask for an architecture diagram from a past project with the client details removed.
5. How do you handle integrations with EHRs and other systems?
Integration is where many healthcare products slow down. Ask which standards the team has used (FHIR, HL7), how they test against vendor sandboxes, and what happens when an EHR vendor changes an interface.
6. How do you handle scope, timeline and ownership?
Ask how work is broken into milestones, what you see at the end of each one, and who owns the code, the cloud accounts and the documentation. You should own all three, and the contract should say so. Ask how a handover works if you later bring development in-house.
7. Who will actually work on my product?
Ask for the names, roles and healthcare experience of the people on your team, not the company's overall headcount. Check time zone overlap with your team and how often you will meet.
Red flags, and the proof to ask for
These answers should make you cautious:
"We are HIPAA certified." HHS does not certify or endorse specific technology or products (HHS cloud computing guidance). A certificate can show good security practice, but it does not make anyone HIPAA certified. Ask what it covers.
No clear answer on PHI in development. If developers routinely work with real patient data, ask why.
Reluctance to sign a BAA or to name subcontractors. If the partner will handle PHI, this is a basic requirement.
Fixed promises with no discovery. A firm date and scope before anyone has looked at your integrations or data usually means hidden risk.
You will not own the code or the cloud accounts. Insist on ownership in writing.
Only prototypes in the portfolio. Healthcare products that are live with real users are the stronger signal.
Ask for evidence rather than assurances. Useful proof includes:
A reference call with a client whose product went live.
An architecture diagram from a past project, with client details removed.
A sample project plan showing security and integration work as planned items.
Independent assessments of the partner's own security, such as SOC 2 or ISO 27001 reports where they exist.
Their written incident response process, including how fast they notify you.
Specialist partner, general agency, freelancers or in-house
There is no single right answer. Match the option to your stage and your risk.
Healthcare specialist partner: strongest when you need a compliant product in production and want security, integrations and delivery handled together. Confirm the team on your project has healthcare experience, not only the company.
General software agency: strongest when the product holds no PHI, or compliance is handled by another party. HIPAA knowledge may be thin, and PHI practices may be missing from their normal process.
Freelancers: strongest for a small, well-defined piece of work from someone you already trust. Watch for no shared process, uneven security practices, and a BAA for every individual.
In-house team: strongest when the product is your core business and you can hire and retain healthcare engineers. Watch for hiring time, and the cost of building security and compliance know-how from scratch.
Hybrid (partner plus in-house lead): strongest when you want a partner to build now and your own team to take over. Agree on documentation, code ownership and handover from day one.
If you already have a pilot or prototype, the key question is who can carry it through security review, integrations and launch. That is the gap a specialist partner is meant to close.
A simple scorecard and a two-week evaluation plan
Score each partner from 0 to 2 on each of the seven questions: 0 for no clear answer, 1 for a general answer, 2 for a specific answer backed by evidence. A total of 11 or more out of 14 is a strong candidate. Any 0 on questions 2, 3 or 4 (PHI handling, BAA, security architecture) is worth resolving before you go further.
You can finish an evaluation in two weeks:
Days 1 to 3. Shortlist three partners. Send each the same written questions so the answers are comparable.
Days 4 to 7. Compare the written answers and ask for the BAA, a sample project plan and an architecture example.
Days 8 to 10. Hold reference calls with clients whose products went live. Ask what went wrong and how the partner handled it.
Days 11 to 12. Have your own technical lead review the architecture example and ask follow-up questions.
Days 13 to 14. Score, decide, and agree on a first milestone small enough to test the working relationship.
How Bitsol approaches the same questions
Bitsol is an engineering partner for healthcare products, with 50+ projects delivered. We take healthcare AI pilots to HIPAA-compliant, enterprise-ready production in 8 weeks, which means security, integrations and launch are planned from the first week rather than added at the end. We are happy to answer the seven questions above in writing and to walk your technical lead through an example architecture.
To see how a fixed 8-week build works, read about our 8-week HIPAA-compliant MVP launch. For an overview of our services, see our HIPAA-compliant app development company page.
FAQ
How long does it take to choose a HIPAA development partner?
A focused evaluation can be done in about two weeks if you send every shortlisted partner the same written questions and book reference calls early.
Is there an official list of HIPAA-compliant developers?
No. HHS does not certify or endorse specific technology or products, so you have to check each partner's practices yourself.
Do I need a BAA before the partner sees any data?
If the partner will create, receive, maintain or transmit PHI for you, yes: a BAA should be in place before any PHI is shared. If the partner works only with synthetic or de-identified data, ask how that boundary is enforced.
Should I choose a specialist or a general agency?
If your product handles PHI, a partner with healthcare delivery experience usually reduces risk, because security, integrations and BAA practices are part of how they already work. A general agency can fit when the product holds no PHI.
What should I own at the end of the project?
The source code, the cloud and vendor accounts, the documentation and the deployment process. Put this in the contract so a handover is possible later.
Conclusion
The best way to choose a HIPAA-compliant development partner is to ask specific questions and weigh the evidence: live healthcare products, careful handling of PHI, a clear BAA position, a security architecture they can show you, and a team you can name. Use the scorecard, hold reference calls, and agree on a small first milestone before committing to a larger build.
Sources: Healthcare Dive on the Bessemer, AWS and Bain healthcare AI adoption report and HHS cloud computing guidance.
