Backend-Only vs. Full-Platform HIPAA: What a Bolt-On Backend Doesn't Cover

A business associate agreement (BAA) is a written vendor contract about protected health information (PHI) handled within the provider's covered service. Signing it does not determine whether your whole app, data flow, and organization meet their applicable HIPAA duties.

‍

For healthcare founders choosing a HIPAA compliant backend, that distinction changes what you're buying and what your team still needs to deliver. Consider a hypothetical digital health startup building a telehealth MVP: the database provider offers a BAA, and a hospital security questionnaire asks how the product controls patient access and handles incidents. The contract helps answer the hosting question; the application and operating questions still need their own answers.

‍

Before you commit, compare the scope layer by layer and put the remaining work into a build and operating budget. That gives you a decision rule: choose backend-only when your team can own the rest, and evaluate a fuller platform when you need help delivering it.

‍

‍

Does a backend BAA make the whole app HIPAA compliant?

A backend BAA does not establish compliance for the whole app; it covers the provider's defined service scope. Your organization still needs to assess application safeguards, other PHI-handling services, risk analysis, and operating duties according to its HIPAA role.

‍

‍

Key takeaways

• ‍A backend BAA applies to PHI and services within its defined scope. Your application and operating duties still need assigned owners and verification across the actual data flow. Use the agreement to identify the provider's boundary.‍
• The cost decision is the work needed to close the remaining gaps. Compare application controls, integrations, and vendor contracts alongside risk analysis and maintenance. Hosting fees are one part of that ownership budget.‍
• Backend-only can fit a team able to own the rest of the product. A fuller platform can reduce app-layer build work when its verified features match your needs. The regulated organization still owns its legal and operating decisions.

‍

‍

What a HIPAA backend covers and what it doesn't

Start with the service you're actually purchasing. A backend vendor may provide storage and hosting safeguards, including encryption at rest and encryption in transit within its environment. Those controls matter, but their reach follows the architecture and written agreement. They don't tell you how your app handles a patient record once someone opens it.

‍

If you're buying HIPAA compliant database hosting, confirm which database service and configuration the BAA covers. If you're buying HIPAA compliant application hosting, confirm the application environment covered by that separate description. Neither market phrase defines the contract for you, and the two purchases can cover different parts of the same product.

‍

Ask where the vendor's responsibility ends and yours begins. A backend access log may show a connection to the database while leaving you unable to explain which clinician viewed or exported a record through the app. That distinction becomes practical when you review permissions and application activity.

‍

The Security Rule is technology-neutral, so assess the safeguards your actual environment needs rather than treating one encryption implementation as a universal recipe. The eight gaps below give you a way to assign the remaining work.

‍

What backend-only and full-platform products mean here

You're comparing how much of the product you buy and how much you build. Here, “backend-only” means a scoped infrastructure purchase; “full platform” means a broader app-building offer whose individual features still need verification. “Full-platform HIPAA” is a comparison label, not an HHS certification or a substitute for legal compliance. Ask each vendor which application and operating tasks its offer helps you carry out, then compare those answers against the product you need to deliver.

‍

Backend-only: BaaS, databases, and hosting with a BAA

You can purchase backend as a service (BaaS) to supply parts of the infrastructure your application uses. Depending on the vendor's offer, that purchase may cover

• a database,
• file storage,
• or hosting under a defined BAA.

Your team then builds the app code around those services and decides how the product uses them.

‍

When you search for a HIPAA compliant cloud database, check the contract and required configuration before placing PHI there. The description alone doesn't establish that your project, environment, or deployment is covered. Hosted Supabase, for example, has specific plan, agreement, and add-on conditions that we'll examine below.

‍

This route gives you a concrete service boundary to work from. It also leaves the application boundary with your team:

• What patients and clinicians can do.
• How those actions are recorded.
• Which other tools receive data.

Scope that work alongside the backend purchase instead of discovering it during review.

‍

Full platform: app layer, workflows, and compliance tooling

You may want help building the product above the database as well. A fuller platform can offer app-layer building, workflows, and review tooling alongside infrastructure. If those features match your needs, they can reduce the engineering work your team takes on. Verify each feature and the BAA scope in writing, because the category name doesn't establish what any vendor delivers.

‍

The decision is how much useful implementation help you gain. Your organization still needs owners for clinical, privacy, legal, security, and operational decisions, including its own risk analysis where applicable. A platform can help you build controls without deciding every use of PHI on your behalf. Ask the vendor to connect its offer to your actual workflow, then identify which decisions and recurring activities remain with your team.

‍

A BAA allocates duties; it does not finish compliance

Before choosing a vendor, establish your organization's role. A covered entity is an organization covered by HIPAA, such as a healthcare provider when its activities meet the applicable conditions. A business associate handles PHI on behalf of a regulated party. Your startup may occupy that second role, while a consumer-directed arrangement may fall outside HIPAA; the relationship and activities decide. The business associate agreement then addresses the relevant vendor relationship.

‍

For your purchase, a shared responsibility model is the written allocation of safeguards between provider and customer. Under HHS cloud guidance, a cloud provider storing or processing electronic PHI for a regulated party is generally a business associate, including encrypted storage the provider cannot view. Confirming HIPAA compliant hosting therefore means confirming written service scope and control ownership. Your organization still needs to assess its whole PHI flow and conduct its own risk analysis. A covered entity contracts with its business associate, which contracts with PHI-handling subcontractors; each service's role needs evaluation.

‍

The HIPAA Security Rule grounds that work in administrative safeguards, physical safeguards, and technical safeguards across the electronic PHI environment, as the HHS Security Rule summary explains. These include:

• access and audit controls,
• authentication,
• and transmission protection.

The rule is flexible and technology-neutral, while addressable specifications still require appropriate consideration rather than being automatically optional. Document who implements each safeguard and how you verify it. That allocation leaves privacy decisions and breach-response duties to be addressed alongside storage security, according to your organization's applicable role.

Supabase and Firebase show why service scope matters

You need a service-level answer before putting PHI into a familiar platform. The examples below use vendor documentation checked for October 2026 and illustrate how the covered service, signed BAA, and customer configuration fit together. They also leave the rest of your data flow and other vendors to evaluate. Read each as a scoped purchasing path: a brand name alone cannot answer whether your particular deployment fits it.

‍

Supabase: a BAA plus customer configuration

You can use hosted Supabase for PHI projects when its stated conditions are met. If you're asking “is Supabase HIPAA compliant,” the scoped answer is a signed BAA, the HIPAA add-on, and at least the Team plan for the BAA path. Those conditions apply to the hosted product rather than establishing a claim about self-hosted deployments.

‍

Your configuration remains part of the purchase. Supabase's shared responsibility model assigns representative tasks to the customer: HIPAA-project designation, multi-factor authentication (MFA), point-in-time recovery (PITR), SSL enforcement, network restrictions, and connection logging. PHI must stay out of public Storage buckets. That list shows meaningful project work; it isn't the whole organization's HIPAA program.

‍

Supabase states that “the responsibility of applying the recommended controls falls directly to the customer.” Supabase's HIPAA compliance page provides that statement in its discussion of customer duties. Its Security Advisor can flag issues, while you apply the controls; it doesn't make the changes for you. Assign someone to that configuration work and assess the wider app separately. The BAA's service coverage doesn't assess the complete product.

‍

Firebase: covered services are named, not bundled

You need to identify the exact Google service behind your app. The question “is Firebase HIPAA compliant” cannot be answered for the suite as a whole. Google's BAA terms apply to named Covered Services when the BAA is accepted, with customer configuration and application duties still to address.

‍

As checked in October 2026, Google's covered-services list displays a September 17, 2025 list date and names:

• Firestore,
• Cloud Storage,
• and Identity Platform.

Service-specific PHI limitations still apply, including Google's limits for Identity Platform. Base Firebase Authentication and Firebase Authentication with Identity Platform have different BAA coverage. Likewise, Cloud Storage for Firebase adds client and access paths around a Google Cloud Storage bucket; the bucket's listing alone doesn't establish coverage for every Firebase feature.

‍

Google's HIPAA guide puts the customer boundary plainly: “ultimately you are responsible for evaluating your own HIPAA compliance.” Use that boundary when reviewing SDKs as well. Google Analytics offers no BAA, and Google says not to send it PHI. This is an Analytics-specific restriction, not a verdict that every Firebase or Google Cloud service is prohibited.

‍

Eight gaps a bolt-on backend leaves open

Your next task is to assign the work beyond the covered backend. These eight gaps describe areas to scope and verify, rather than eight automatically failed HIPAA requirements. Some work may already be complete; some may be covered by another written agreement. For each area, identify the control owner, test a concrete failure path, and ask what evidence would answer the buyer's question. That gives you a usable product review instead of a generic compliance checklist.

‍

Frontend and mobile app security

Your patient-facing screen can expose data even when the database's safeguards work as intended. Assess how the frontend or mobile app handles PHI through local storage, caching, screenshots, and session management. Infrastructure encryption doesn't determine what remains visible on a screen or available after a session ends.

‍

Consider a hypothetical patient record that remains in an app's local cache after sign-out. Your team needs to understand whether it can still be accessed, what the workflow requires, and which safeguards address the risk. That example identifies a behavior to assess; it doesn't establish that every cache, screenshot, or local store violates HIPAA.

‍

Ask your application owner to demonstrate the screen and session behavior with test data. Include the patient and clinician paths your product actually supports, then record the decisions in the wider risk analysis. The backend vendor's service agreement cannot answer those app-code questions for you.

‍

Patient and provider permissions

You need to decide which records each person can access through your product. HHS requires controls for authorized electronic PHI access, while your team maps those requirements to patients, clinicians, and administrators in its own data model and workflows. Role-based access is one design approach; the Security Rule doesn't mandate one named RBAC implementation.

‍

Review whether your access controls reflect the intended relationships between people and records. A hypothetical administrator permission that exposes more patient data than intended gives you a concrete question to test before a security review or during operation. Assign the application owner to verify the permission boundaries.

‍

The HIPAA Privacy Rule also governs uses and disclosures of PHI. Its minimum necessary standard has exceptions, including treatment disclosures to a healthcare provider and disclosures to the individual. Keep those distinctions in the access design rather than applying one blanket rule to every workflow.

‍

Application-level audit trails

You may have database connection records and still struggle to explain what happened to a patient record. Under HHS audit-control requirements, assess whether your audit logs capture the relevant activity in the application. Login records alone may not answer who viewed, changed, or exported data through the product.

‍

For a hypothetical record export, ask your application owner to show the event and connect it to the user action. Then decide:

• Which events the product needs to record.
• Who reviews them.
• Who can access the records themselves.

Set retention according to your actual requirements.

‍

The useful evidence is a demonstrated activity trail and an assigned review process. A backend may contribute infrastructure records, but you still need to verify how those records answer questions about patient and clinician actions.

‍

Video, messaging, push, and analytics services

Your telehealth MVP may use third-party integrations for video calls, messaging, push notifications, and analytics. Map the data each service actually receives. A notification might contain no PHI, or its content might reveal patient information; the payload and workflow determine what you need to assess.

‍

Assign an owner to review each PHI-handling service's role and agreement. A business associate or PHI-handling subcontractor generally needs the relevant BAA, and your backend's agreement doesn't extend to a separate provider. Google Analytics is a concrete boundary: Google offers no BAA for it and instructs customers not to send it PHI. Apply that specific restriction without treating every analytics service as identical.

‍

Include development and AI tools in due diligence when they may touch PHI. The question is Claude Code HIPAA compliant belongs in that review alongside the tool's intended data access. Keep the inventory tied to actual data flows, so you can identify which contracts and safeguards each service needs.

‍

EHR and lab integrations

Your app can connect successfully to a clinical system while the permitted data flow remains unresolved. For an EHR integration or lab integrations, separately check the technical connection, data mapping, access permissions, transmission safeguards, and contracts. Calling a connection a HIPAA compliant API doesn't decide who is allowed to disclose which information.

‍

Determine each party's role. A vendor acting as a business associate or subcontractor generally needs the relevant BAA. A provider-to-provider treatment disclosure doesn't automatically make the receiving provider a business associate. The contract decision follows the relationship and permitted disclosure, rather than the mere presence of an API.

‍

Ask your integration owner to walk through a hypothetical record transfer:

• What leaves the app.
• Where it arrives.
• Who can access it there

Record the permission and agreement basis alongside the data mapping. The database purchase alone cannot establish those external boundaries.

‍

Logs, error tracking, and backups

You need to inspect the copies of data your product creates outside its main database. Error tracking, logging, backup exports, and file storage may contain PHI, depending on what your application sends or saves. Give the owner of each destination a concrete question: what data can reach this tool, and which agreement covers that use?

‍

A hypothetical error report containing patient information shows the failure path. The original database may sit inside the backend's BAA while the separate error-tracking service remains outside that contract. Assess the report's contents and destination before assuming the storage agreement covers the copy.

‍

Apply the same review to exported backups and stored files without assuming they all contain PHI. This gives you evidence for a security review and a clearer view of possible breach exposure. Assign someone to maintain the destination inventory as the product changes.

Risk analysis, policies, and workforce training

You still need time and people for recurring organizational work after buying hosting. Start a risk assessment with the electronic PHI your actual product creates, receives, maintains, or transmits. HHS's formal risk analysis considers that environment; a vendor's infrastructure controls cannot substitute for your own analysis where it applies.

‍

Assign owners for policies and procedures and workforce training within the administrative safeguards your organization needs. Those activities require time as well as documents. Decide who maintains them and how your team will show that the work has been carried out.

‍

Return to the hypothetical MVP's hospital security questionnaire. If it asks for evidence of risk analysis or training, the hosting BAA answers a different question. Your organization needs its own evidence for those activities. This is a resourcing issue to put into the ownership budget, without assuming every hospital asks the same questions or predicting a fixed launch delay. Make the recurring work visible before committing your development capacity elsewhere.

‍

Breach response and notification

You need an incident response path that reaches beyond the backend vendor. Under the HHS Breach Notification Rule guidance, breaches of unsecured PHI can create notification duties, including a business associate's notice to the covered entity. The covered entity's responsibilities and recipients differ from the associate's; your organization's role matters.

‍

Ask who escalates a hypothetical issue first noticed in the app, how the backend and other service owners join the response, and who handles the applicable notification decisions. Put those responsibilities in a documented path rather than relying on the backend's incident process to settle every duty.

‍

Not every security incident is a reportable breach. Analysis, recipients, and timing depend on the incident and regulated party, so a single universal deadline would obscure the decision. Assign the response owners before an incident leaves you trying to reconstruct the contractual boundaries.

‍

The hidden cost of closing the gaps yourself

You can compare offers more fairly once the remaining work has an owner and an estimate. Treat HIPAA compliant cloud hosting as one budget line, then add application engineering and operations. Configuration, BAAs, testing, and review belong in the purchase decision alongside monitoring and maintenance. Broader healthcare app development scope is where much of that work becomes visible.

‍

Use this worksheet with actual vendor quotes and your development team's staffing estimates. For each gap, record:

• One-time engineering or setup effort.
• Known external service or BAA fees.
• Recurring monitoring and policy or training work.
• The accountable owner.

Price the effort before adding it to the total.‍

First-year total = setup + first-year services + operations. Disclose potential exit and migration costs separately.

‍

This turns time to market into a capacity question: what can your team deliver while completing the required work? During due diligence, the hypothetical security questionnaire may reveal an unassigned control that needs more engineering or evidence. Estimate that work instead of assuming a cheap hosting line means a cheap first year

‍

Backend-only versus full platform: compare the whole scope

You should be able to place both offers in the same table. Compare the layer each purchase covers and the work someone still has to own. A full-platform cell describes a possible broader offer, so confirm it against the vendor's actual feature set and written contract before treating it as delivered.

Use the final column to test both proposals. When a vendor promises help, ask which task it performs and what evidence it supplies. Your applicable legal and operating duties remain to be assigned even when the platform handles more product work. The useful comparison is the written control split across your actual workflow.

‍

When backend-only is enough

You can choose backend-only sensibly when your development team can own the rest of the product. That means building and maintaining the application layer, evaluating PHI data flows, and working with the owners who carry out risk analysis, policies, and contract review. The deciding evidence is a written service scope and a control-owner map that accounts for the remaining work.

‍

For the hypothetical MVP, ask whether the team can demonstrate the patient and clinician permission boundaries, record relevant activity, and review the external services it adds. Then check who maintains those controls after the initial build and who resources the organizational duties. Calling the release an MVP doesn't change its applicable HIPAA obligations.

‍

A technically capable team may prefer this route because it can make and maintain the application decisions itself. Put that capacity into the budget rather than assuming the tasks are absorbed by the backend. If each remaining responsibility has an owner and the team can verify it, the scoped infrastructure purchase can fit. If you can't yet assign that work, resolve the ownership question before treating the BAA as enough.

‍

When a full platform makes more sense

You may get more value from a fuller platform when your team needs help delivering the app layer. Permission flows, review tooling, or managed delivery can make a broader offer useful, provided the vendor actually supplies the parts your product needs. Ask it to demonstrate those features against your workflow and confirm the related service and BAA scope in writing.

‍

In the hypothetical telehealth MVP, consider whether your team wants to build the patient and clinician experience itself or obtain help with telehealth app development. Compare that help against the engineering capacity and operating work in your worksheet. A platform that handles relevant implementation tasks can reduce the build burden, while unrelated tasks still need owners.

‍

Where HIPAA applies, your organization's regulated role and responsibilities continue alongside that help. Clinical, legal, privacy, and compliance decisions remain to be made for your actual product and relationships. The purchase makes sense when the verified feature scope solves the work you need help with, and the residual responsibility map is still complete. Choose on that evidence rather than the breadth of the platform label.

‍

Questions to ask any HIPAA vendor before signing

Bring your intended PHI flow to the conversation and ask for answers you can locate in a contract or product document. Before committing, confirm your organization's HIPAA role, intended PHI flows, and contract obligations with a healthcare attorney. A digital health app isn't automatically regulated merely because of its category.

• ‍Contract and scope: Which legal entity signs the BAA? Which services, plans, environments, and subprocessors are covered? Where may PHI flow, and which relationships need separate agreements?‍
• Application controls: Who configures access and audit controls? Who reviews the app, and what evidence shows that the controls fit your patient and clinician workflows?‍
• Operating ownership: Who owns risk analysis, policies, and training? How are incidents escalated between your team, the backend provider, and third-party services?‍
• Cost and exit: What is the all-in ownership cost? What can you export, what dependencies remain, and what work would an exit require? Can the vendor provide a written responsibility map?

Use the security questionnaire to organize evidence for these answers. During due diligence, check the actual service boundary and control allocation rather than relying on a badge. HHS certification guidance explains that HHS neither endorses nor recognizes private certifications as proof of Security Rule compliance. Third-party assessments can exist, but they don't discharge legal duties. Written scope gives you something concrete to evaluate before signing.

‍

How Specode can help

Specode brings the application layer into the purchase. Its healthcare application builder lets you define a responsive web application's UI, workflows, data model, permissions, and integrations from plain-English requirements. Your team directs product decisions and validates the application before production.

‍

Specode's HIPAA Agent scans code already inside your project from the Compliance Center, without a separate upload, and reports findings across eleven categories. It separates issues it treats as must-fix from recommended hardening. You can:

• Send a finding to the AI coder for a fix.
• Re-run the scan after changes.
• Compare saved scan scores over time.

Before production, a Specode team member performs one security and HIPAA readiness review. The scan and single pre-go-live review support readiness work alongside your own risk analysis and legal, privacy, security, and compliance reviews; they don't determine compliance or guarantee an outcome.

‍

Specode production hosting runs in your own Convex account, with coverage for that hosting relationship through Convex's standard BAA, which you sign. On Custom, Specode also signs a separate BAA with you. The hosting agreement covers its service scope; app controls and other PHI-handling services need their own assessment, and the Specode team helps identify relevant third-party BAAs.

‍

Specode Pro gives you guided help from the team: senior product manager consultation, hands-on weekly team support, bug fixes, and small implementations. Custom offers a hands-off app build and maintenance service. You retain clinical, legal, privacy, and compliance ownership, including risk analysis and third-party BAAs.

‍

With Specode, you retain rights in your generated data, content, code, and applications, and can export code and applications during your subscription and for 60 days after termination, excluding Specode platform IP and third-party services. Specode migration starts with a team conversation and supports code already in, or exportable to, a GitHub repository. Your team owns the configuration, maintenance, security, compliance review, and costs of the integrations it manages.

‍

To scope your HIPAA compliant app, book a demo to see how Specode can help build it and map its data flow, BAAs, and remaining control owners with the team.