Which App Builders Sign a HIPAA BAA?

A customer with health records asks one question before anything else gets signed: will the platform your app runs on enter into a business associate agreement. This page is about the US rules that bind an app holding health records on behalf of a covered entity or one of its business associates, not about a patient’s own rights over their chart, and not about the sense in which a builder’s marketing page calls itself HIPAA compliant. A business associate agreement, usually shortened to BAA, is the written contract that makes that relationship lawful.

The reason the question is hard to answer is that the app already exists. It was built on Lovable or Base44 or Replit or Bolt, it stores its data in Supabase or Firebase, it deploys through Vercel or straight onto AWS, and the clinic that wants to buy it is asking about all of them at once.

Nine platforms, read on 3 September 2026 from the pages each company publishes itself. Five publish a route to a business associate agreement. The four AI builders that founders actually ship on name no such agreement on any page this reading could open, and one of them bars health records in its terms outright unless it agrees otherwise in writing first.

Everything below is a reading of nine companies’ own published pages, every one of them pulled in raw form on 3 September 2026, twice, once as an ordinary client and once wearing a browser’s own identification, and read from the top of the markup to the bottom of the footer, with the page named and the date given wherever a fact carries weight. The regulation’s own text supplies what a business associate agreement has to contain. AxonBuild did not build, sign, host, audit, test, run or configure any part of it. Nothing on this page decides whether a reader’s app satisfies the health rules, and nothing on it is a lawyer’s opinion.

What a business associate agreement is, and who has to sign one

A business associate agreement is the written contract a covered entity signs with an outside company that handles protected health information on its behalf, and 45 CFR 164.504(e) sets out what that contract has to make the company promise. It binds the two parties by law. No badge, certificate or audit report substitutes for it.

The definitions sit in 45 CFR 160.103, read here on 3 September 2026 in the annual revision the Government Publishing Office publishes for 2025. A covered entity means, in the regulation’s own words, “(1) A health plan. (2) A health care clearinghouse. (3) A health care provider who transmits any health information in electronic form in connection with a transaction covered by this subchapter.” A business associate means a person who, on behalf of such a covered entity and other than as a member of its workforce, “creates, receives, maintains, or transmits protected health information for a function or activity regulated by this subchapter”. The same section states that a business associate includes “a subcontractor that creates, receives, maintains, or transmits protected health information on behalf of the business associate”, which is how the chain reaches down through a software company to the database and the host underneath it.

What the contract itself has to do is set out at 45 CFR 164.504(e), in the same annual revision. The section says a contract between a covered entity and a business associate must “Establish the permitted and required uses and disclosures of protected health information by the business associate”, and must provide that the business associate will not use or disclose the information other than as the contract or the law permits, will “Use appropriate safeguards”, will “Report to the covered entity any use or disclosure of the information not provided for by its contract”, and will “ensure that any subcontractors that create, receive, maintain, or transmit protected health information on behalf of the business associate agree to the same restrictions and conditions”. Those are the clauses a platform is agreeing to when it says it will sign.

There is no certificate for any of this. Google Cloud’s HIPAA compliance page states it plainly: “there is no certification recognized by the US HHS for HIPAA compliance and … complying with HIPAA is a shared responsibility between the customer and Google.” AWS says the same thing about itself: “There is no HIPAA certification for a cloud service provider (CSP) such as AWS.” A vendor that hands you a certificate has handed you a document about a different question.

Who signs a HIPAA business associate agreement, across nine platforms

Five of the nine platforms below publish a route to a business associate agreement on their own pages, and every one of those five sits underneath the builder rather than being the builder. The column headings are the only three questions the table tries to answer, and it ranks nothing.

Two things the table can tell you. Every published route has a gate on it, and no gate is a setting inside the app: it is a conversation, a console step or a plan. And the four columns are all the same shape, which means the four rows that say “not on the pages read” are saying something narrow and checkable, not something absolute. Each of those four is spelled out below with the exact pages and the exact date.

Netlify is not on the list. The nine are the builders founders ship on and the platforms those builders put underneath them, and every other host answers the same question on its own pages in its own words.

What no table of this kind can tell you is whether the agreement, once signed, covers what your app actually does. Four of the five published routes name what the agreement applies to and stop there. That limit is the subject of the section further down, and it is the part that catches people who read the top row of this table and stop reading.

The four AI app builders, and what each one publishes about health data

Not one of the four builders names a business associate agreement on any page this reading could open. Two of them do address health data, and both do it in their terms as a restriction rather than an offer. The third says nothing about it anywhere readable, and the fourth attaches the word HIPAA to a deployment shape most of its customers are not using.

Lovable: health records barred unless separately agreed

Lovable’s terms are the most explicit of the four on health records, and what they say is a prohibition. Lovable’s terms, in the version their own page dates Last Updated 28 August 2026, say that unless your plan or a separate written agreement with the company, “such as a data processing addendum or enterprise service agreement”, expressly permits it, you agree not to provide through the services “any protected health information subject to HIPAA, or other special or sensitive categories of data”, and that the standard services “are not designed to serve as a system of record for, or to provide regulatory-grade safeguards for, such data”. As of 3 September 2026, Lovable’s security page does not contain the words HIPAA, business associate or protected health information anywhere in its raw markup, navigation and footer included; its own compliance question is “Is Lovable SOC 2 or GDPR compliant?” and it answers only those two. The trust centre at trust.lovable.dev returns a client-rendered shell with 20 characters of readable text to an automated read, on 3 September 2026, to a plain request and a browser-shaped request alike. What Lovable’s security page does say it supports, and what its certificates cover, is in the Lovable safety review. Whether Lovable’s own pages have changed their answer on health records since this reading is a question in its own right. The SOC 2 report, the processing agreement and the region question are a different set of paperwork with a different answer.

Base44: the same gate, in different words

Base44’s terms of service put the same gate in different words: the customer warrants that no sensitive data “protected under special legislation and requires unique treatment (such as protected health information or credit, debit or other payment card data) will be shared with the Platform”, except where the company has “expressly agreed” beforehand in writing and the right agreement exists. Read whole on 3 September 2026, its trust page at base44.com/security gathers GDPR, ISO 27001 and a SOC 2 Type II report under the heading “Compliance, covered”, and contains no occurrence of HIPAA, business associate or protected health information; the same is true of base44.com/dpa. A separate host at trust.base44.com did not resolve at all on 3 September 2026, to a plain request or a browser-shaped one, so nothing here rests on it. What Base44’s trust center names, and what its plans gate, is worked through in the Base44 compliance breakdown.

Replit: nothing in the readable terms

Replit’s terms of service run to roughly 23,000 characters of readable text and contain no occurrence of HIPAA, business associate or protected health information, read whole on 3 September 2026 with the navigation included. Two more pages a buyer would try, replit.com/security and trust.replit.com, each return a client-rendered shell of under 60 characters to an automated read, on 3 September 2026, to a plain request and a browser-shaped request alike. The platform controls Replit documents are set out in the Replit safety review. What Replit publishes about its own reports, and how a buyer requests them, is a separate reading.

Bolt: one HIPAA sentence, attached to your own cloud account

Bolt is the one builder whose pages use the word HIPAA at all. Bolt’s security page says “Bolt is SOC 2 Type 2 certified and compliant with GDPR and CCPA”, and its single HIPAA sentence answers the question “Can I deploy Bolt in my own cloud?” with “Yes. BYOK deployment lets you run Bolt inside your own AWS or Azure tenant with full infrastructure isolation and no shared compute, meeting HIPAA, FedRAMP, and SOC 2 requirements.” The words business associate and protected health information do not appear on that page. Its customer assurance profile at trust.bolt.new, last updated 8 July 2026, lists its certifications as SOC 2 Type 2, GDPR and CCPA, and contains none of the three phrases either. So the claim on the page is about a deployment a customer runs in their own cloud account, and it names no agreement. The earlier dated read of what Bolt publishes is in the Bolt.new safety review; the pages at bolt.new/security and bolt.new/terms returned their site navigation and no body text to an automated read on 3 September 2026, again to both request shapes.

The platforms underneath, and how far their agreements reach

Every published route in this territory belongs to a platform the builder sits on top of. Four of the five spell out both halves: the step that produces the agreement, and the list of services the agreement then applies to.

Supabase: a signed agreement, an add-on, and a project setting

Supabase’s HIPAA Projects guide states that “You can use Supabase to store and process Protected Health Information (PHI)” and that to start you “reach out to the Supabase team here to sign the Business Associate Agreement (BAA)”. It sets two conditions in one sentence: “Organizations must have a signed BAA with Supabase and have the Health Insurance Portability and Accountability Act (HIPAA) add-on enabled when dealing with PHI.” With the add-on on, projects can then be configured as High Compliance in the General Project Settings page, after which Supabase runs continuing checks against a named configuration list. Its HIPAA compliance guide is unusually direct about who is what: “Supabase acts as a business associate for customers (the covered entity)”. The same guide describes the chain of agreements running downward, saying “Supabase has signed a Business Associate Agreement (BAA) with all of our vendors who would have access to ePHI, such as AWS”. Which plans carry the add-on, and what it costs, is answered in the Supabase HIPAA review. Supabase’s answer on European data protection sits in a different set of documents again.

Firebase and Google Cloud: the covered products list decides

Google Cloud’s HIPAA compliance page says “Google will enter into Business Associate Agreements with customers as necessary under HIPAA”, and gives the route as an account step: “Execute a Google Cloud BAA. You can follow the instructions in the Privacy compliance and records for Google Cloud to review and accept the BAA.” It then tells customers to “Disable or otherwise ensure that you do not use Google Cloud Products that are not explicitly covered by the BAA (see Covered Products) when working with PHI”, and separately not to use Pre-GA offerings with health records unless a notice says otherwise. The Covered Products section itself begins “The Google Cloud BAA covers Google Cloud’s entire infrastructure (all regions, all zones, all network paths, all points of presence), and the following products”, and then lists them by name. Read against the whole raw page including its product navigation menu on 3 September 2026, that list names Firestore and Identity Platform. Read the same way, the Firebase brand name occurs on that page only inside the site’s own product navigation, where “Cloud Storage for Firebase” is listed as a link out to a different product area, and inside two of the page’s script-level feature-flag names. It does not occur once inside the Covered Products section. The page also says of that list: “This list is updated as new products become available to the HIPAA program.” How Google splits responsibility for a Firebase project is covered in the Firebase security review. Which individual Firebase services sit inside Google’s covered list, and which do not, is a longer answer than one cell.

AWS: an addendum in the console, and eligible services only

AWS’s HIPAA compliance page says “AWS has a standard Business Associate Addendum (BAA) we present to customers for signature”, and gives a console route: “To review, accept, and manage the status of the BAA for your account, sign in to AWS Artifact in the AWS Management Console.” The limit sits in the next answer: “Customers may use any AWS service in an account designated as a HIPAA account, but they should only process, store, and transmit protected health information (PHI) in the HIPAA-eligible services defined in the Business Associate Addendum (BAA).” The page also answers the question a software company selling to clinics actually has. Asked whether its customers need their own agreement with AWS, it answers “No”, explains that “You as the AWS SaaS partner sign a Business Associate Addendum (BAA) with AWS. Then each healthcare provider or covered entity signs a BAA only with you, the AWS SaaS partner”, and adds that a covered entity using AWS directly for its own systems may need both.

Vercel: two of its own pages disagree

Vercel’s own pages give two different answers on the same day, and the honest version of this row names all three pages. Vercel’s knowledge base guide, whose own structured data gives 3 November 2025 as the publication date and 10 November 2025 as the last modification, opens “Vercel supports HIPAA compliance for Pro and Enterprise customers”, and splits the route: “For Enterprise customers subject to HIPAA and processing PHI within their websites or applications, Vercel will sign a BAA”, while “For Pro customers, the BAA is a click through agreement that is not signed.” Vercel’s changelog entry of 9 September 2025 puts it as an announcement: “Pro teams can now enter into a Business Associate Agreement (BAA) to support HIPAA-compliant workloads on Vercel. The BAA is available self-serve through the dashboard with no Enterprise contract required.” Meanwhile Vercel’s security page, read on 3 September 2026, still answers its own question “Does Vercel support HIPAA compliance?” with “Vercel supports HIPAA compliance for enterprise customers.” Two of Vercel’s pages say Pro and one says enterprise only, so a buyer quoting the security page and a buyer quoting the guide will disagree with each other while both are quoting the vendor. The certifications Vercel publishes, and what each one covers, are set out in the Vercel safety review.

Why an agreement with the platform underneath does not reach the builder above it

A signed agreement covers the services the agreement names, and the builder’s own layer is not among them. Google’s page names its covered products and tells customers to keep health records out of everything else; AWS says the same about its eligible services. The editor, the agent and the preview host sit outside both lists.

This is the part that catches founders who did the paperwork properly and still have a gap. Two of the published routes above make the limit explicit in their own words, and they are worth reading side by side. Google’s page tells customers to disable or avoid Google Cloud products “that are not explicitly covered by the BAA”, and its Covered Products section is a finite list of names that ends. AWS’s page says customers may use any service in a HIPAA account but should only process, store and transmit health records “in the HIPAA-eligible services defined in the Business Associate Addendum”. Both companies are describing the same mechanic: the agreement is a contract over an enumerated set of services, and the enumeration is where the coverage stops.

Now put the builder back on top of that. What a founder buys from Lovable, Base44, Replit or Bolt is an editor, an agent that writes and runs code, a preview environment that serves the app while it is being built, a deployment surface, and the vendor’s own logging and support tooling. The database sits under all of it, owned by somebody else. Every one of those builder-side pieces belongs to a different company from the one that signed the agreement over the database. None of them appears on Google’s Covered Products list or in the addendum AWS presents in Artifact, because those lists name their own company’s services and nobody else’s.

Supabase’s own documentation shows the correct shape of the chain, and it does not go upward. Its guide says Supabase “has signed a Business Associate Agreement (BAA) with all of our vendors who would have access to ePHI, such as AWS”. The agreements run downward, each party binding the party it depends on, exactly as the regulation’s subcontractor clause describes. Nothing in that chain obliges the builder that generated the app to join it, and none of the four builders’ pages says it has.

So the practical answer to “the database signed, am I covered” is that the database signed for the database. What the editor saw while the app was being built, what the agent logged, what the preview environment served and to whom, and what the builder’s support team can reach are all separate questions, and on 3 September 2026 none of the four builders’ pages answered any of them in writing.

The eight questions to send a platform before real records go in

Every one of the nine leaves something open, and the openings are specific enough to write down. These are questions to send the vendor and keep the written reply to. None of them is answered by a setting inside the product.

1. Will you enter into a business associate agreement for this account, and on which plan does that become available?
2. Which of your services does the agreement name, and which of your services must the app therefore keep health records out of?
3. Does the agreement cover the editor, the code-generating agent, the preview environment and the build logs, or only the running application?
4. Where does the agreement say health records may be stored, and does that include backups, replicas and support access from other places?
5. Which of your own subcontractors touch that data, and have they signed the same restrictions that 45 CFR 164.504(e) requires a business associate to pass down to them?
6. What is your reporting obligation to us when something goes wrong, and what triggers it?
7. When the account closes, what happens to the data, in what form, and who confirms it?
8. If a page of yours says one thing and another page says something else, which one is the contract?

Question 8 is not a joke, and Vercel’s three pages are the reason it is on the list. A vendor whose published pages disagree with each other is telling you that the answer lives in a document you have not read yet.

Knowing who signs is the first half; what has to move inside an app that already holds records is the other half.

None of that is compliance work. No agreement gets drafted or negotiated here, no assessment gets approved, no platform gets certified, and no reader’s duties under the health rules get decided by anything written above.

Common questions about app builders and HIPAA agreements

What is a business associate agreement, and who has to sign one?

A business associate agreement is the contract that lets an outside company create, receive, maintain or transmit protected health information for a covered entity, and 45 CFR 164.504(e) says what it has to contain: the contract must establish the permitted uses and disclosures, require appropriate safeguards, require the company to report any use or disclosure the contract does not provide for, and require it to bind its own subcontractors to the same restrictions.

Does a platform’s SOC 2 report cover the health records in my app?

A SOC 2 report and a business associate agreement are different documents answering different questions, and holding the first says nothing about the second. Bolt’s customer assurance profile, last updated 8 July 2026, lists its certifications as SOC 2 Type 2, GDPR and CCPA, and names neither HIPAA nor any agreement. Base44’s trust page groups three headings of the same kind, and HIPAA is not among them.

If the database underneath my app signs an agreement, is my app covered?

The database signed for the database. Google Cloud’s page tells customers not to use products “that are not explicitly covered by the BAA” with health records, and AWS’s page restricts them to the eligible services named in its addendum, so both agreements are contracts over an enumerated set of one company’s own services. The builder that generated the app, its editor, its agent and its preview hosting are a different company and a different question.

Is there a HIPAA certification an app builder can hold?

Both of the cloud providers that address this head on say no such certificate exists. Google Cloud’s compliance page states that “there is no certification recognized by the US HHS for HIPAA compliance”, and AWS’s page states that “There is no HIPAA certification for a cloud service provider (CSP) such as AWS.” A vendor offering a HIPAA certificate is offering something those two pages say is not available to it.

What the paperwork and the assessment work actually cost is its own question.

Who is the covered entity if my customer is the clinic and I am the software?

AWS answers this one directly for its own customers. Asked whether covered entities buying a partner’s software also need their own agreement with AWS, its page answers “No”, and explains that “You as the AWS SaaS partner sign a Business Associate Addendum (BAA) with AWS. Then each healthcare provider or covered entity signs a BAA only with you, the AWS SaaS partner.” The page adds that a covered entity using AWS directly for its own systems may need both.

Does the AI agent inside the builder see the records my app stores?

None of the four builders’ pages read on 3 September 2026 states what its code-generating agent can reach in a running application’s data, and none names an agreement that would cover it. The closest published guidance comes from Google, whose HIPAA page tells customers not to use Pre-GA offerings, meaning products in preview programmes, with health records unless a notice for that offering says otherwise.

What happens to an app that already holds health records on a platform with no published agreement?

Lovable’s terms answer that for Lovable, and the answer is not comfortable reading. They say that if you provide such data in violation of the clause, “you do so at your own risk”, that you are solely responsible for having a lawful basis and any required consents, that you agree to indemnify the company for claims arising from it, and that the company “may remove such data or suspend the associated Services” where it becomes aware of non-compliant use.

What should I ask a platform in writing before real records go in?

Ask which plan makes an agreement available, which of the vendor’s services the agreement names, whether it covers the editor and the agent as well as the running app, where the data may sit including backups and support access, which subcontractors touch it, what the vendor must report to you and when, and what happens to the data when the account closes. Keep the written reply, because a vendor’s published pages can contradict each other and the contract is what settles it.