4 min read

What AI-built healthcare apps miss about BAAs

What AI-built healthcare apps miss about BAAs

A founder built a healthcare app for around $8,000 using AI coding tools. The demo worked. The pilot clinic was sold. Then the vendor questionnaire arrived: business associate agreements, encryption at rest, audit logs, role-based access control, breach notification procedures. The rebuild ran roughly three times the original cost.

The story, shared in a Reddit AI-builder community, points to a problem healthcare startups keep hitting at procurement. AI coding tools can ship working software fast. They cannot tell a founder what HIPAA expects from a vendor handling protected health information.

 

What happened

The founder behind the post reportedly spent around $8,000 building an AI-assisted healthcare minimum viable product (MVP), which is an early-stage version of a product designed with just enough core features to test whether the idea works in real-world conditions before investing in a full-scale build. The application functioned as intended, the demo was well received by a pilot clinic, and the project appeared ready to progress to the next stage. Then the vendor questionnaire arrived. The clinic started asking questions about:

The founder could not confidently answer the questions because "the developer had not thought about any of it.” According to the post, the application eventually had to be rebuilt at roughly three times the original cost.

 

The gap

“Cursor doesn’t know what a BAA is.” That single sentence perfectly captures one of the biggest gaps in today’s AI-assisted healthcare development space.

Tools like Cursor, Claude Code, Lovable, Bolt, and v0 make it possible to build polished applications at an incredible pace. Solo founders and small teams can now launch MVPs in days instead of months. However, healthcare software is not evaluated solely on functionality; it is also evaluated on whether it can safely and compliantly handle protected health information (PHI). This is where many AI-built healthcare apps begin to struggle.

 

Why BAAs matter

The U.S. Department of Health and Human Services (HHS) states that “The HIPAA Rules generally require that covered entities and business associates enter into contracts with their business associates to ensure that the business associates will appropriately safeguard protected health information.” The BAA is required whenever a vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity. This makes BAAs a foundational compliance mechanism rather than an optional legal formality.

They formally define how a vendor must safeguard PHI, limit its use and disclosure, report security incidents. They also require that subcontractors handling the same data are held to equivalent standards. Without a signed BAA in place, a healthcare provider cannot lawfully delegate PHI-related functions to a third-party service.

 

The email blind spot

Email infrastructure is one of the biggest blind spots in AI-built healthcare apps. As Paubox’s Paubox's 2026 healthcare email security report states, “170 email-related breaches hit healthcare organizations in 2025, exposing 2.5 million patient records.” This shows how frequently email systems are implicated in healthcare security incidents, particularly when they are not configured or governed according to healthcare compliance requirements.

Paubox survey data shows that 60% of healthcare organizations have experienced accidental PHI exposure via email, and 23% report unauthorized access to patient data through email in the past 12 months.

Many founders building MVPs with AI tools default to services like SendGrid, Postmark, Resend, and other generic Simple Mail Transfer Protocol (SMTP) providers. These tools are attractive because they are easy to set up, inexpensive, commonly recommended, and simple to integrate into modern applications. However, healthcare communication introduces more stringent requirements.

The question should not be “can this send an email?” Rather, the question to ask is, "can this provider securely handle PHI under HIPAA requirements?”

PHI shows up in more places than founders expect:

  • Password reset emails may contain identifiable information
  • Appointment reminders may contain PHI
  • Onboarding workflows may reference patient data
  • Intake confirmations may contain sensitive details
  • Lab notifications may expose regulated information

If the vendor handling those messages won't sign a BAA, the organization is already out of compliance.

 

Closing the gap

According to the Reddit post, “Retrofitting it costs more in time, money, and customer trust than building around it from day one.” Healthcare startups rarely fail because the product is bad. They fail because compliance and procurement get treated as Phase 2 work. By the time vendor reviews start, the fix usually means structural changes to infrastructure, workflows, and third-party dependencies. The longer it waits, the more it costs.

Paubox research found that 85% of healthcare organizations reported at least one email-related breach in the past year, and 60% admit their email security measures are inadequate. For a startup trying to land its first clinic, that's the bar to clear.

Rebuilding the whole app usually isn't the answer. The biggest risks tend to sit in infrastructure decisions, not the core product. A founder may not need to redesign the app, rewrite backend logic, or rebuild workflows. Swapping non-compliant communication infrastructure for healthcare-ready alternatives often closes the gap.

When evaluating email infrastructure, founders should prioritize vendors that offer:

  • Signed BAAs
  • Encryption in transit and at rest
  • Audit logging
  • Secure SMTP relay options
  • Controlled administrative access
  • Healthcare-focused infrastructure

 

A healthcare-ready alternative: Paubox Email API

One example of how this gap is being addressed in practice is purpose-built healthcare email infrastructure, such as the Paubox Email API. Unlike general-purpose email services that require additional configuration or separate compliance agreements, Paubox is designed specifically for healthcare use cases where PHI may be transmitted by default.

According to Paubox documentation, its email API allows developers to “send transactional, HIPAA compliant email through your apps and software,” with built-in support for programmatic delivery, encryption, and audit visibility. This means developers can integrate email into healthcare applications using either REST or SMTP without rethinking the entire application architecture while still maintaining HIPAA compliant safeguards such as encryption in transit and at rest, and a signed BAA as part of the service.

See also: HIPAA Compliant Email: The Definitive Guide (2026 Update)

 

FAQs

What should founders look for in healthcare-ready email providers?

Key requirements include a signed BAA, encryption in transit and at rest, audit logging, secure SMTP or API access, controlled administrative permissions, and infrastructure designed for regulated healthcare environments.

 

How can startups reduce compliance risk early?

By selecting infrastructure vendors that are already healthcare-ready, ensuring BAAs are in place early, and designing systems with data privacy, auditability, and secure communication flows in mind from the start.

Subscribe to Paubox Weekly

Every Friday we bring you the most important news from Paubox. Our aim is to make you smarter, faster.