HIPAA-compliant software is software that handles protected health information with the safeguards the law requires: signed business associate agreements with every vendor that touches the data, technical controls like encryption, access management, and audit logging, and documented policies for the people who operate it. There is no certificate that makes you compliant. It's an ongoing obligation, and it either shapes your architecture from day one or gets expensively retrofitted later.
This guide is for founders planning a product that touches health data: what actually falls under HIPAA, what "compliant" means in engineering terms, where AI features quietly create risk, and what all of it means for your budget. One caveat up front: we build HIPAA-compliant systems, and we aren't lawyers. Legal questions about your specific product belong with a healthcare attorney, and that fee is some of the best money an early healthtech founder can spend.
HIPAA regulates two groups. Covered entities are the obvious ones: providers, health plans, and clearinghouses. Business associates are everyone who handles protected health information on a covered entity's behalf, and that's where most healthtech startups land. If your platform stores, processes, or transmits patient data for a clinic, a home-health agency, or an insurer, you're in scope, and your customers will expect you to sign a business associate agreement before any data moves.
Protected health information, or PHI, is health information tied to an identifier: a name, an email, a device ID, a date of birth. The pairing is what matters. A heart-rate reading by itself isn't PHI; a heart-rate reading attached to an account is. Some direct-to-consumer wellness products that never touch a covered entity's data sit outside HIPAA entirely, though other privacy laws still apply. Where exactly your product lands is the question to put to that attorney.
The law describes safeguards in three buckets: administrative (policies, training, risk analysis), physical (facilities and devices), and technical. The technical safeguards are the ones that shape a software build, and they translate into concrete architecture decisions:
None of these are exotic. All of them are dramatically easier when the data model, the permission system, and the logging pipeline are designed for them from the start.
No government body certifies software as HIPAA-compliant. A vendor waving a "HIPAA-certified" badge is describing a marketing decision. What exists instead is the ongoing practice of compliance: risk assessments, safeguards, agreements, and documentation, maintained for as long as you handle PHI. Third-party audits and attestations can be genuinely useful evidence for enterprise buyers, but they attest to how you operate, and how you operate can drift. Treat compliance as a property of your architecture and your habits, never as a plaque on the wall.
Your product doesn't run in isolation. It runs on a hosting provider, sends email, tracks errors, and maybe transcribes audio or calls an AI API. Every vendor in the path of PHI needs a signed business associate agreement, and one missing link breaks the chain no matter how good your own controls are.
The major clouds (AWS, Azure, Google Cloud) will sign BAAs covering specific eligible services, and part of compliant architecture is staying inside that eligible list. The sharper problem is the long tail of convenient tools: analytics trackers, session-recording widgets, logging services, and support inboxes that were never built for PHI and won't sign an agreement. Compliant builds route identified health data away from those tools entirely.
AI is showing up in healthtech roadmaps everywhere, and it's where we see the most accidental exposure. The common failure modes are mundane:
Compliant paths exist for all of this. Some AI providers will sign BAAs on enterprise tiers with zero-retention configurations, and de-identifying data before it leaves your system is often a workable design. The point is that these are architecture decisions someone has to make deliberately, feature by feature, before launch. An AI feature bolted on in a sprint is how a clean system becomes a liability.
Compliance woven in from the start is mostly a set of early decisions: which services you're allowed to use, how the data model separates identifiers from health data, where encryption and logging live. Made at architecture time, those decisions add modest, predictable scope.
Retrofitting inverts that. Adding role-based access to a system that never had it touches every endpoint. Adding audit logging after the fact touches every table. Swapping a non-compliant vendor means migrating live data, and every change lands on a product that's already serving users, so the whole surface gets re-tested. Teams that defer compliance to "after we get traction" end up paying for large parts of the build twice. The pattern is reliable enough that we treat "we'll add HIPAA later" as a signal to slow a project down and rescope it.
A compliant build is a custom software build with a stricter set of constraints, and the constraints show up in the price. The typical ranges in our software cost guide are the right baseline for standard products; a HIPAA-compliant product usually starts above the entry point of a comparable standard build and lands toward the top of those ranges or past them, because the access, encryption, logging, and vendor constraints add scope to every feature they touch. That premium is smallest when compliance is designed in from day one, which is exactly why doing it early is cheap and doing it late is brutal.
Plan for ownership costs too. The usual 15 to 20 percent of build cost per year for maintenance matters more here, because compliance is operational: dependencies get patched, access gets reviewed, vendors change terms, and your risk analysis has to stay current. We've kept HIPAA-compliant systems healthy for years under our support memberships, and the short version of what that covers is in our FAQ on HIPAA-compliant web applications.
Whether you're vetting us or anyone else, five questions separate teams that have shipped compliant systems from teams that have read about them:
A team that answers those in specifics, with decisions they've defended in a real customer's security review, is a team you can build with. Vague reassurance about "bank-level security" is the other kind of answer.
Every expensive HIPAA mistake we've been called in to fix traces back to a decision made before development started, usually by default rather than on purpose. The fix is to make those decisions explicit while they're still cheap: map where PHI flows, list every vendor in its path, pick the services that will sign BAAs, and design the data model around the safeguards.
That's the work our Discovery package front-loads. In two to three weeks you get a requirements document, API and vendor recommendations, development considerations including the compliance constraints above, line-item pricing, and a timeline. Kickoff is 7 to 10 business days after signing, and the deliverables are yours to build with, whether with us or any team you choose.
Planning a product that touches patient data? A fixed-price Discovery maps your PHI flows, your vendor chain, and your real build cost before you commit to development. Or talk to us and we'll tell you honestly whether HIPAA applies to what you're building.
Written by Jeremy Millian, COO at Iron Forge Development, a U.S.-based software commercialization firm that has helped launch 100+ products from idea to market.
A founder's primer on HIPAA-compliant software: who the law covers, the technical safeguards that shape architecture, the BAA chain, where AI features create risk, and why compliance belongs in discovery rather than a post-launch retrofit.
Choosing who builds your software is a high-stakes decision. Here's how to weigh agencies, freelancers, and offshore teams — the criteria that matter, the questions to ask, and the red flags to avoid before you sign.
An MVP is the smallest product that does one valuable job for real users. Here's what that means in practice: what to include, what to cut, what it costs, and how to scope yours without guessing.
