Patient portals, intake flows, triage tools, EHR integrations, internal workflows. Senior engineer on subscription, HIPAA-aware from day one. $4,999/mo.
- Scope
- Ship
- Iterate
monthly subscription
Who this is for
Clinic owner, healthtech founder, or healthcare-ops lead who needs custom healthcare web app development because the off-the-shelf EHR does not fit the workflow and the patient portal is a third-party afterthought bolted on by the vendor.
The pain today
- Off-the-shelf EHR does not match your actual clinical workflow
- Patient portal is a clunky vendor bolt-on your patients barely use
- Intake still runs on paper or an unencrypted web form
- Staff coordinate care in spreadsheets and group email threads
- A previous developer shipped code with no BAA, no audit logs, no RBAC
The outcome you get
- Custom healthcare web app on subscription at $4,999/mo
- HIPAA-aware architecture with signed BAAs in place before a line of code ships
- Patient portal, intake tool, or clinical workflow app delivered in 6 to 12 weeks
- Immutable audit trails and role-based access controls on every surface
- Clean code handoff to your in-house team or a full-time hire when you are ready
What HIPAA-aware architecture actually looks like
Custom healthcare web app development is not just a matter of adding a checkbox to a form. HIPAA has three categories of safeguards that a web application handling PHI must address. Administrative: access control policies, workforce training records, audit procedures, and a signed BAA with every vendor that touches PHI. Physical: HIPAA-eligible hosting (AWS and Google Cloud both sign BAAs for their eligible service tiers), backup procedures, and disaster recovery. Technical: encryption at rest and in transit, unique user IDs, automatic session timeouts, multi-factor authentication, role-based access control, and immutable audit logs.
The common failures I see when I inherit a healthcare codebase: PHI stored in a system with no BAA in place, third-party analytics or logging tools ingesting PHI because nobody scoped them out, patient data passing through email attachments, audit trails that cover only logins but not reads and writes to clinical records, and access controls that are a single admin flag in the database.
I build around these from day one. Encrypted storage (AES-256 at rest, TLS 1.2+ in transit), BAA-covered hosting on AWS or Google Cloud, row-level security and RBAC enforced at the database layer, every sensitive action logged with actor, patient ID, action type, timestamp, IP, and user agent. That logging goes to a dedicated store separate from application data, retained to meet HIPAA's six-year requirement.
Custom healthcare web app on subscription at $4,999/mo
Healthcare apps I build and the ones I do not
The custom healthcare web apps I build sit around the EHR, not inside it. Full EHR replacement is a specialist vendor category (Epic, Athena, Cerner, DrChrono) and not something I compete with.
What I do build: digital intake and pre-visit screening forms that replace paper and insecure email. Patient portals where patients can message their provider, view lab results, access visit documents, and complete pre-visit questionnaires. Scheduling tools for specialty visit types, cohort scheduling, or anything beyond what the EHR's scheduling module handles. Internal clinical workflow tools: referral tracking, case management queues, billing workflow dashboards. Clinical reporting dashboards for administrators and practice managers. FHIR API integrations between the EHR and a third-party data store.
I also build telehealth-adjacent tooling: pre-visit intake automation, async symptom triage, post-visit follow-up workflows. I do not build the video call infrastructure itself (that is Twilio Video or Daily.co territory), but I build the workflow that sits around it.
For most single-clinic operators, configuring an existing EHR beats a custom build every time. Custom work makes sense when the EHR blocks a specific workflow that is materially strategic to your practice: a new service line, specialty-specific intake, non-standard scheduling logic, or reporting your EHR cannot generate.
2M+: Records processed.
EHR integrations: FHIR, HL7, and what to expect
Most modern EHRs expose FHIR R4 APIs for patient demographics, clinical records, appointments, and observations. Athena, DrChrono, NextGen, and Epic App Orchard all support FHIR to varying degrees. That is the cleanest integration path: OAuth 2.0 app registration, SMART on FHIR scopes, standard resource reads and writes.
Legacy EHRs without REST APIs use HL7 v2 messaging over an interface engine. Mirth Connect is the open-source standard. The integration is slower to build and more brittle to maintain, but it is the only option for systems that predate REST APIs.
What to budget: a FHIR integration against a well-documented modern EHR takes four to six weeks. A legacy HL7 integration takes six to ten weeks. Every integration is developed against a sandbox environment and load-tested before touching production data. I never connect a new integration to live PHI without a staging validation period.
BAAs, penetration testing, and security before launch
Every healthcare engagement starts with a BAA before any code is written. The BAA covers how I access PHI during development, breach notification obligations, and data disposal after the engagement ends. The default development approach is to use synthetic data only during build, which keeps real PHI out of local environments entirely.
Hosting BAAs: AWS signs BAAs for their HIPAA-eligible services (S3, EC2, RDS, CloudWatch Logs, and others). Google Cloud signs a BAA covering equivalent services. Aptible bundles compliance infrastructure and is a strong option for practices that want managed compliance without a dedicated DevOps budget.
Before a healthcare app touches real patient data, it goes through a penetration test and a dependency vulnerability scan. I use OWASP Top 10 as a baseline for the security review. SQL injection, broken authentication, insecure direct object references, and misconfigured CORS headers are the most common findings in healthcare web apps built without a security-first mindset. These are caught in code review and pen testing, not after a breach.
Pricing and what the subscription covers
Standard plan is $4,999/mo. Pro is $5,499/mo. Both include senior engineering, HIPAA-aware architecture, and 2 to 4-day delivery cycles. Pro adds priority response and faster turnaround for urgent clinical or compliance requests.
The 14-day money-back guarantee applies to the first payment. Cancel anytime after that. Every line of code is yours under Work Made for Hire from the first sprint. NDA is standard.
Hosting costs are separate and billed directly to you: AWS, Google Cloud, or Aptible depending on scale and compliance posture. Typical range is $200 to $2,000 per month depending on data volume and traffic. You own the hosting accounts. You own the BAAs with the hosting providers. I never hold customer infrastructure accounts.
For context, a project-based agency build for a patient portal typically runs $80,000 to $200,000 upfront with no ongoing engineering support. The subscription model gives you a senior engineer continuously across the full build, not a fixed handoff at the end of a project.
Performance in clinical environments
Clinicians do not have patience for slow pages. A patient portal that takes four seconds to load lab results will not be used. Staff workflow tools that lag under load create real patient safety risk when information retrieval slows down at peak hours.
At Cuez I took API response times from 3 seconds to 300 milliseconds, a 10x improvement, while cutting infrastructure costs by roughly 40 percent. The approach was the same one I apply to healthcare apps: query analysis, caching strategy, index optimization, and eliminating N+1 patterns before they reach production.
For healthcare apps specifically, database design matters more than in typical SaaS. PHI is sensitive, so column-level encryption is common, and encrypted queries are slower than plain queries. Getting that architecture right from the start prevents a painful retrofit when performance degrades at 10,000 patient records. I design the data layer for query performance and compliance at the same time, not as separate concerns.
When to build custom versus configuring your EHR
The honest answer: for most single-clinic operators, a well-configured EHR like Athena, NextGen, or DrChrono handles 80 percent of clinical workflows out of the box. Configuration is faster, cheaper, and lower risk than custom development.
Custom healthcare web app development makes sense when one or more of these apply: your clinical workflow is genuinely non-standard and the EHR's configuration options do not cover it; you are building a healthtech product for external customers rather than internal staff; your intake or triage process involves logic the EHR form builder cannot express; or you need reporting and analytics the EHR's built-in reports cannot generate.
The clearest signal is when staff have built shadow systems in spreadsheets or external tools to work around the EHR's limitations. When the workaround is the workflow, that is a custom-build problem.
Recent proof
A comparable engagement, delivered and documented.
Four systems, one source of truth: HubSpot visibility for one of Brazil's largest vet networks
Built a custom integration layer for Reevia that connects four source systems into HubSpot for one of Brazil's largest veterinary companies. Over 2 million records processed with full normalization. Any lead from any system is inside HubSpot in under 50 seconds, standardized and ready to use.
Read the case studyFrequently asked questions
The questions prospects ask before they book.
Yes, before any engagement that touches PHI. I sign a standard HIPAA Business Associate Agreement in the first week. It covers how I access PHI during development, breach notification procedures, and data disposal at engagement end. For builds where development runs entirely against synthetic data, the BAA is still worth having before production troubleshooting access is ever needed. NDAs are separate and also standard.
AWS or Google Cloud with their HIPAA-eligible service tiers and signed BAAs. Aptible is a managed-platform alternative that bundles compliance controls — faster to get running, slightly higher monthly cost. For smaller practices without dedicated DevOps budget, Aptible is usually the right call. For larger operations, direct AWS or GCP is more flexible. You own the hosting account and the BAA with the provider from day one.
Modern EHRs expose FHIR R4 APIs (Athena, DrChrono, NextGen, Epic App Orchard). I register the app, handle OAuth 2.0 and SMART on FHIR scopes, and work against the EHR's sandbox before touching production. For legacy systems without REST APIs, HL7 v2 via Mirth Connect is the standard path. Budget four to six weeks for a modern FHIR integration and six to ten weeks for a legacy HL7 integration.
Before any healthcare app touches real patient data, it goes through a pen test and a dependency vulnerability scan. I use OWASP Top 10 as the baseline: SQL injection, broken authentication, insecure direct object references, CORS misconfiguration, and session management. Findings get addressed before go-live. This is not optional — it is part of the standard build process for every healthcare engagement, not an add-on.
Every read and write to PHI logs an immutable entry with actor ID, patient ID, action, timestamp, IP, and user agent. Logs go to a dedicated store separate from application data, either AWS CloudTrail, a dedicated Postgres audit schema, or a purpose-built audit log service. Retention meets HIPAA's six-year requirement. Compliance reports and breach investigation exports are generated on demand.
Web apps on mobile browsers cover most patient use cases: messaging providers, viewing results, booking appointments, completing intake. I ship responsive, PWA-ready code that installs to the home screen. Native iOS or Android is worth the additional investment only when you need offline access, device hardware (camera for wound photos, microphone for voice intake), or OS-level push notifications. I do not build native mobile apps.
A project-based agency build for a patient portal typically runs $80,000 to $200,000 upfront with a handoff at delivery. At $4,999/mo you get a senior engineer continuously across the full build and into iteration. No handoff gap, no re-engagement fee when you need a change six months later. The tradeoff is predictable monthly cost versus a single large capital outlay.