A healthcare software development company that gets patient data right.
We build the software behind healthcare products: patient-facing apps, clinical dashboards, and the scheduling and data layers underneath them. We've already shipped a GDPR-compliant patient data system for a European clinic, and we design every regulated-data project around access control, audit trails, and encryption from the start, not bolted on after a client asks.
What we've built
Two real healthcare builds, not a portfolio slide.
We don't have a wall of healthcare logos to show you, and we're not going to pad this page with vague claims to make up for it. Here are the two healthcare-relevant systems we've actually built, described honestly, including what's still small about them.
A GDPR-compliant clinical trial platform for a Netherlands-based clinic
We built a mobile app for patients and a companion clinical dashboard for staff, used to run and monitor botox clinical trials at a Netherlands-based aesthetic clinic. Both were designed GDPR-compliant from the first architecture decision, not retrofitted, because the clinic's patient data is EU-regulated from day one. The engagement is ongoing, and a second project for the same client is underway now. We're not naming the clinic publicly, but the repeat engagement is the part worth noting: they came back for a second build after the first one held up.
Clinic scheduling logic built into a production AI product
ARA AI, our own AI phone receptionist product, has a clinic mode built for exactly this kind of scheduling: multi-doctor availability, service-specific appointment durations, a patient roster with visit history, and automatic new-versus-returning patient detection. Every appointment moves through a status workflow, Pending, Confirmed, Checked In, Completed, No-show, so a front desk can see where a patient actually is, not just what's on the calendar. Patient-data isolation is enforced with Postgres Row Level Security at the database layer, not application checks a future refactor could quietly break.
We build patient-facing apps with Flutter or React Native and Expo, backends in Go or Hono, and data layers on Supabase, AWS, S3, and Cloudflare R2. ARA AI's clinic mode specifically runs on Retell AI for voice, React and TanStack for the dashboard, PostgreSQL with Supabase Row Level Security, Hono for the API, and DIDlogic for telephony. For the full breakdown of the clinic scheduling engine, read the engineering case study.
Want the same care applied to your patient data?
Book a discovery callWhat we build
Healthcare software development, the parts that actually matter.
Whether it's custom EHR development, a patient app, or an internal dashboard, all of it needs the same underlying discipline: data isolation, an audit trail, and a UI a clinician will actually use during a shift.
Patient-facing apps
Mobile and web apps for booking, intake, and patient portals, built with access controls appropriate to the data they hold, not added in after launch.
Clinical dashboards & internal tooling
The software your staff actually opens every shift: multi-provider scheduling, visit history, and status tracking that maps to how a clinic runs, not how a generic CRM assumes it runs.
EHR/EMR integration & custom EHR development
Integrating with what you already run when it exposes a real API, or building a purpose-built system when an off-the-shelf EHR is more constraint than tool.
Scheduling & booking engines
Multi-provider availability, service-specific durations, and a booking flow that checks and re-checks availability before it writes anything.
Regulated data
Regulated patient data, handled properly from day one.
We build systems that hold patient data, and we design for the rules before the first real record exists. Our shipped regulated work to date is GDPR: a patient data system for a Netherlands clinic, built compliant from the start rather than retrofitted. The same controls carry into a HIPAA build, access control, audit trails, encryption, and database-level isolation, and we know in detail where the two regimes stop overlapping. If you are evaluating vendors for HIPAA compliant app development, what follows is what the work actually involves.
GDPR and HIPAA aren't the same law wearing different acronyms
GDPR is horizontal: it covers any personal data, in any industry, the moment an EU resident's data is involved. HIPAA is sector-specific: it only applies to protected health information, and only to covered entities and their business associates. Some engineering practices transfer directly: encryption at rest and in transit, audit trails, tenant isolation at the database layer. The legal instruments don't. A GDPR Data Processing Agreement is not a Business Associate Agreement, and one doesn't substitute for the other.
The moment PHI is in scope, we become a business associate
A development contractor that creates, receives, maintains, or transmits protected health information on a client's behalf is a business associate under HIPAA, and needs a signed BAA before that access starts, not after. The infrastructure underneath needs its own BAA too. Not every vendor, and not every plan tier, offers one: some hosting and database providers only sign a BAA on their higher-priced tiers, and some don't offer one at all. We check that per vendor, per engagement, before we commit to a stack.
"Addressable" doesn't mean optional
HIPAA's Security Rule splits some technical safeguards into required and addressable specifications. Required means implement it. Addressable means assess whether it's reasonable for your system, implement it if so, and if not, implement an equivalent control and document why. Skipping an addressable control and writing nothing down is the one path that's actually non-compliant. A 2025 proposal would tighten several of these into flat requirements, but it hasn't been finalized, so today's assess-implement-document framework is still what's operative.
The disqualifiers we design against from the start
PHI in application logs. PHI in analytics or session replay tools. PHI sitting in a URL or query string. Unencrypted backups. No audit trail on who read a record, not just who wrote one. Shared admin logins. None of these are exotic mistakes. They're the ordinary defaults of a fast-moving build, and they're exactly what turns into a real problem in a regulated system. We design them out before the first PHI record exists, not after.
In practice
What HIPAA compliant app development actually requires
"HIPAA compliant" isn't a feature you bolt on at the end. It's a set of decisions that change what data an app is allowed to touch, which vendors it can run on, and what has to be true before a single real patient record enters the system. Here's what that looks like once it leaves the acronym and becomes actual engineering work, the same operational understanding that applies to HIPAA compliant software development more broadly.
What counts as PHI, and when an app is actually in scope
Protected health information is any individually identifiable health data created, received, maintained, or transmitted by a covered entity or its business associate, in any form: a field in a database, a line in a support ticket, an attachment in an email. The same appointment note is PHI when a clinic's app holds it, and outside HIPAA's reach entirely when a general fitness app holds the identical data, because the law is triggered by who is holding it, not by how sensitive the data looks. Scoping an app correctly starts with mapping every place PHI could land, not assuming it stays inside the obvious patient-record table. For how this compares to GDPR's approach to the same data, see our breakdown of HIPAA vs. GDPR for healthcare software.
PHI can enter through pieces you didn't think of as "the app"
The BAA obligation follows actual PHI handling, not proximity to a healthcare client, and it doesn't stop at the development team. An analytics SDK, a logging pipeline, an SMS or voice provider, a crash reporter: any piece of the stack configured to actually carry PHI needs its own BAA to be viable for that role, and it may not be able to sign one depending on which plan or tier a project defaults to. That has to be settled as an architecture decision before code is written, not discovered after PHI is already flowing through a vendor that can't cover it.
The Security Rule, translated into what you actually build
In an actual app, HIPAA's technical safeguards resolve into specific choices: a unique login for every person and every service account, never a shared one; a documented emergency-access path for when normal login is unavailable; encryption for PHI at rest and in transit; and an audit log that records who read a record, not just who wrote one, reviewed by someone rather than left to accumulate. Some of these are labeled addressable rather than required, but addressable means assess whether it fits your system, implement it if so, and document the decision either way. It never means skip it.
Where the disqualifiers actually come from in a real build
PHI in logs, in analytics, in a URL rarely start as a decision anyone made on purpose. A logging library that serializes full request bodies by default will log PHI without a single line that says to. A crash reporter or session-replay tool wired in for debugging captures whatever was on screen when it fired, PHI included, unless it's explicitly told not to. A shareable link with a patient identifier in the query string outlives the link itself in referrer headers and server access logs. None of this is named in HIPAA's text; it's the ordinary, well-understood way a fast-moving build violates the general risk-analysis obligation by default, and it's what we configure against before the first PHI record exists.
How we work
What hiring us actually looks like.
We've delivered 23+ projects end to end. For a regulated-data build, the Roadmap Sprint doubles as healthcare IT consulting: two weeks mapping what counts as PHI in your system, where a BAA becomes necessary, and which vendors in your stack can actually sign one, before a single line of production code touches real patient data.
Step 1
Book a discovery call, or start with a Roadmap Sprint
If PHI and compliance scope still need mapping, the Roadmap Sprint is a $2,500, two-week audit: what counts as PHI in your system, feasibility, and a prioritized plan. If you move forward, the full cost is credited toward the build.
Step 2
Start within 48 hours
Most engagements begin within 48 hours of the discovery call, with a scope and a sprint plan that already covers where PHI touches the system, not a month of estimates.
Step 3
See a working build in one to two weeks
Weekly delivery from there. You talk to the people building it and reviewing the compliance scope, not an account manager relaying updates.
That's the whole process. No proposal deck, no procurement runaround.
Start a projectFAQ
Questions worth asking before you hire a healthcare software development company.
What regulated healthcare data have you worked with?
Our shipped regulated work to date is GDPR: a patient data system for a Netherlands-based clinic, designed compliant from the start to handle EU patient data, with patient and tenant isolation enforced in the database rather than in application code. A HIPAA build carries the same controls plus what that regime adds on top: a signed BAA before anyone touches PHI, audit trails on reads and not just writes, encryption in transit and at rest, and documentation behind every addressable safeguard. Tell us what your data actually looks like on the discovery call and we will scope it precisely.
Is GDPR compliance the same as HIPAA compliance?
No. GDPR is horizontal and applies to any personal data across any industry. HIPAA is sector-specific and only covers protected health information handled by a covered entity or its business associates. Some engineering practices carry over directly: encryption, audit trails, database-level tenant isolation. The legal instruments don't. A GDPR Data Processing Agreement is not a Business Associate Agreement.
Will you sign a BAA?
Yes, when the engagement puts us in contact with real PHI. A development contractor that creates, receives, maintains, or transmits PHI on a client's behalf becomes a business associate under HIPAA and needs a signed BAA before that access starts. We also check that the infrastructure underneath, hosting and database included, can sign its own BAA, since not every vendor or plan tier offers one.
Is there such a thing as a 'HIPAA certified' app?
No, and it's worth being skeptical of any vendor who claims one. There's no official HIPAA certification for cloud providers, AWS says so directly on its own compliance pages, and no equivalent certifying body exists further up the stack either. What actually exists is a signed BAA with every vendor in the stack that touches PHI, safeguards implemented against the Security Rule's required and addressable specifications, and documentation behind every decision. 'HIPAA compliant' describes an ongoing set of practices and contracts, not a badge earned once and displayed forever.
Can you integrate with our existing EHR or EMR?
That depends on what your EHR actually exposes. Some have a real API, some export files on a schedule, and a few offer neither. We scope the integration path during the Roadmap Sprint instead of promising a generic answer, because the honest scope changes with the vendor.
How fast can you start, and how fast will I see something working?
Most engagements start within 48 hours of the discovery call, and you'll see a working first build within one to two weeks.
Do you build AI or voice agents for healthcare settings?
We've built clinic scheduling logic into ARA AI, our own AI phone receptionist product: multi-doctor availability, a patient roster with visit history, new-versus-returning detection, and an appointment status workflow from Pending through Completed or No-show. The voice agent itself is English only today. We'd scope a healthcare voice product the same way we scope everything regulated: what data it touches, and what has to be true before it goes live.
Ready to build the healthcare software behind your product?