I’ve shipped a HIPAA-compliant EHR holding 2M+ medical records at 99.99% uptime for ChiroSimple — a U.S. clinic network, on a Flutter + Firebase stack, migrating from a legacy WordPress + MySQL system. I’m not a compliance lawyer. But I know what separates developers who can actually ship HIPAA-ready systems from developers who say they can.
Here’s what you should be asking before you hire.
1. Ask about their threat model, not their certificate wall
“I’ve worked on HIPAA systems before” means almost nothing. What you want to hear is how they think about PHI (protected health information) flow. Ask:
- Where does PHI live in the system you’ve built? Database rows, logs, backups, caches, queues, analytics events, crash reports. A senior developer will mention at least five of these unprompted.
- How do you prevent PHI from leaking into logs? The correct answer involves structured logging with a field-level allowlist, not “we just don’t log PHI.” “We just don’t log PHI” is how PHI ends up in logs.
- How do you handle encryption at rest? Cloud default is fine, but they should know which default — and when it isn’t enough (e.g. for field-level encryption of SSNs or diagnosis codes).
- What’s your backup restore SLA? If they’ve never restored a backup, they don’t have backups.
2. Ask about the BAA chain
HIPAA requires a Business Associate Agreement with any vendor that touches PHI. The correct answer should include a mental map of every third party in the stack and whether each one signs a BAA.
Common gotchas a senior developer should flag:
- Firebase: BAA-eligible under Google Workspace Enterprise + specific Firebase services; not all of them.
- Logging tools (Sentry, Datadog, etc.): most sign BAAs only on their enterprise tiers.
- LLM providers: OpenAI, Anthropic, Google all offer BAAs, but with plan-specific terms. If your system uses any LLM and PHI could end up in a prompt, you need this sorted before the first production deploy, not after.
- Analytics SDKs: Most consumer analytics (Mixpanel, Segment on default plans) do NOT sign BAAs. Devs who’ve shipped HIPAA will have a plan for this.
If a candidate talks about HIPAA only at the framework level (“we used AWS, it’s HIPAA-compliant”) without mentioning the BAA chain, they haven’t shipped it.
3. Ask about audit trails
HIPAA requires audit logs of who accessed what PHI, when, and why. Too many devs treat this as a nice-to-have.
Questions to drill on:
- How do you log access events? Who sees, who edits, who exports.
- How long do you retain audit logs? HIPAA recommends 6 years.
- Can you produce a report of every person who accessed a specific patient record in the last 90 days? If the answer involves log scraping rather than a structured query, it’s not audit-ready.
4. Ask about offline and sync
This is where real-world healthcare systems live or die. Clinics in rural areas lose internet. Doctors see patients in rooms with bad Wi-Fi. An EHR that only works online is an EHR that’s abandoned.
A developer who’s shipped a real EHR will talk about:
- Conflict resolution when two devices edit the same record offline
- Queue persistence so a failed sync doesn’t lose data
- PHI at rest on the device — encrypted, expired on inactivity, wiped on logout
- The offline-first UX problem — what the user sees when a save hasn’t synced yet
If their answer is “we used Firestore’s offline cache,” dig deeper. It’s a fine primitive, but it’s not the whole story.
5. Ask about the migration
If you already have data in a legacy system (and most clinics do), migration is usually where the wheels come off. The developer should have opinions on:
- Incremental vs. big-bang migration. Big-bang is almost always wrong.
- How to run both systems in parallel during cutover. Dual-writes, shadow reads, reconciliation checks.
- What to do when migration finds corrupt data. (It will.)
- Uptime expectations during migration. We held 99.99% during a four-month rollout. That doesn’t happen by accident.
6. Ask for a post-incident story
Every senior developer has one. “Tell me about a time something went wrong in a HIPAA-sensitive system you were responsible for. What did you do?”
Good answers:
- They noticed before users did
- They wrote a post-mortem
- They changed something structural to prevent recurrence
- They talk about both the technical and the human response (did you notify the covered entity? the patients?)
Bad answers:
- “Nothing’s ever gone wrong”
- “That’s legal’s problem”
7. Watch for HIPAA theater
HIPAA theater is when a developer cites compliance language without understanding the underlying rule. Red flags:
- They talk about “HIPAA certification” — there is no such thing for developers. HIPAA compliance is a property of the covered entity, assessed against the Privacy Rule and Security Rule, often audited by third parties but never “certified” for an individual developer.
- They promise the system will be “100% HIPAA-compliant” — compliance isn’t a property of software, it’s a property of how software is used inside a covered entity.
- They haven’t worked with a covered entity’s compliance officer or legal team — real HIPAA projects involve both.
What I’d pay for
A HIPAA-compliant Flutter or web + mobile EHR project, built end-to-end by a senior operator who’s shipped one before, reasonably scopes as:
- Greenfield: $40k–$120k for the initial build, depending on features and migration complexity
- Rescue / compliance retrofit: $20k–$80k, sometimes more if the legacy stack is weird
- Ongoing retainer post-launch: $5k–$15k/month for senior oversight + incident response
If someone quotes you half these ranges, they’re likely either underscoping or planning to staff juniors. If someone quotes you double, they’re probably an agency with overhead you don’t need.
The plain close
If you’re hiring for a HIPAA project and these questions feel useful, let’s talk. I’ve shipped one. I know where the bodies are buried. My services page has the engagement shapes and ranges; my ChiroSimple case study is the specific project this post is drawn from.
And if I’m not the right fit, I’ll tell you that too — and point you at someone better.