In Part 1, AI App Development with Base44: How to Build a Healthcare App (Step-by-Step), Base44 generated MindCare, a patient-therapist scheduling app with search-and-book flows, a therapist dashboard, and seeded demo data.
It worked. But a login screen alone doesn’t stop a patient from reaching another patient’s appointments. Before anyone real uses the app, that has to be enforced on the backend, and you have to decide where the app will actually run. Those two decisions are what it takes to deploy AI apps with Base44 for real users.
Part 1 ended with a follow-up prompt that added sign-up and sign-in. This post shows that prompt in full, and what it enforces beyond the login screen.
This is Part 2 of our Base44 series:
- Part 1: AI App Development with Base44: How to Build a Healthcare App (Step-by-Step)
- Part 2: From AI Prototype to Production Ready: Deploy AI Apps with Base44
- Part 3: How to Make a Base44 App HIPAA Compliant (Step-by-Step Guide)
- Part 4: How to Build a Production-Ready HIPAA-Compliant App with Base44 (Complete Guide)
Step 1: Ask ChatGPT to Audit the Build
Before writing a new prompt, we went back to ChatGPT (not Base44 directly) and described the working Stage 1 build. Then we asked what that same Stage 1 would need for Base44 production deployment, without adding Stage 2 clinical features like intake forms or treatment plans.
The answer came back as a full production-readiness checklist, grouped into seven areas:
- Authentication & User Roles
- Therapist Onboarding & Verification
- Availability & Booking Engine
- Appointment Management & Notifications
- Security, Privacy & Compliance Foundation
- Admin, Monitoring & Infrastructure
- Testing, Accessibility & Launch QA
That’s a lot more than one team tackles in a single pass, and it should be, especially if the goal is to actually deploy AI apps with Base44 rather than just demo one.
For this post, we only implemented the first area, Authentication & User Roles. The other six are real, valid next steps, not filler. Which ones you tackle next (and in what order) depends on your own launch timeline and risk tolerance:
- Therapist onboarding matters more if you have real therapists waiting to join
- Monitoring matters more the closer you are to real users
Treat the list above as a menu, not a mandatory sequence.
This audit is what separates vibe coding a demo from launching a product. It turns “it works” into a list of everything you’ll be responsible for once real users arrive, so you can decide what to fix before launch and what can wait.
Step 2: Build Authentication and Base44 Role-Based Access
Of the seven areas, Authentication & User Roles has to come first, whatever you tackle next. Nothing else on that list matters if a patient can access another patient’s data by editing a URL. Those roles have to be enforced on the backend, not just implied by the UI, or none of the rest of this list is worth doing.
This is also where HIPAA starts to matter. HIPAA’s technical safeguards include access controls, and role-based access is the usual way to meet them: a defined mapping of who can see which fields, not just which pages. Part 3 goes deeper on HIPAA; here, the point is that this work has to happen before production, not after.
Once Authentication & User Roles was picked as the priority, the follow-up ask to ChatGPT was short: give me a prompt for this that I can hand straight to Base44.
What came back was considerably more detailed than that one-line ask, which is worth seeing in full rather than skimmed, so here’s what each part of it is doing.
The full prompt runs to 25 sections. These five do most of the work, and the complete prompt is at the end of this step.
Say what stays untouched before saying what to add
One line here stops a focused request from turning into an accidental full rewrite:
I already have a working Stage 1 MVP of MindCare, a mental-health
therapist discovery and appointment-booking platform.
The existing Stage 1 includes:
- Patient therapist search
- Therapist profiles
- Therapist availability
- Appointment booking
- Patient appointments
- Therapist dashboard
- Therapist appointment details
Do not rebuild or remove these existing features.
For this task, focus ONLY on making Authentication and User Roles
production-ready. Do not add Stage 2 clinical-record features.
- The UI should never be the only security layer.Assign the role once, and never let it change
If users can change their own role, every other permission rule stops meaning anything:
8. Role Assignment
- Patient signup → patient
- Therapist signup → therapist
Users must NOT be able to change their role from the frontend, through a
form, URL parameter, API request, or dev tools. Do not create a public
role-change feature.The backend is what actually enforces access
Hiding a page in the frontend isn’t security. The same check has to happen again on the server, every time:
10. Server-Side Authorization
Do NOT rely only on frontend route protection. Every protected
backend/database operation must verify:
- The user is authenticated
- The account is active
- The role allows the requested action
- The requested record belongs to or is associated with that user
A patient must NOT be able to request another patient's appointments by
changing an appointment ID. A therapist must NOT access another
therapist's appointments by changing a therapist ID.Turn the rules into attacks you actually try
A rule someone can name is easier to skip testing than a scenario someone can literally attempt:
12. Prevent Privilege Escalation
Explicitly test and prevent:
- A patient changing their own role to therapist (denied)
- A patient manually navigating to the therapist dashboard
(denied/redirected)
- A patient changing an appointment ID to another patient's appointment
(denied)
- A therapist changing a therapist ID to another therapist's (denied)
- An unauthenticated user accessing protected data (denied)
- A suspended user accessing the application (blocked)“Done” includes the old features still working
This is the real gate before you deploy AI apps with Base44 to real users:
25. Final Acceptance Criteria
Authorization:
- Every protected route is role-aware
- Backend/database permissions enforce ownership
- Patients cannot access therapist-only functionality and vice versa
- Users cannot modify their own roles or access another user's records
by manipulating IDs
Existing MVP:
- Patient: Login → Search Therapist → View Profile → Book Appointment →
View Appointment
- Therapist: Login → Open Dashboard → View Appointment → View Associated
Patient Information → Update Appointment Status
Do not consider the feature complete until these workflows pass after
the authentication changes.The complete 25-section prompt is below. Click to expand it.
▶ Click to view the full Base44 authentication prompt
Base44 Prompt: Production-Ready Authentication & User Roles
Upgrade Stage 1: Production-Ready Authentication & User Roles
I already have a working Stage 1 MVP of MindCare, a mental-health
therapist discovery and appointment-booking platform.
The existing Stage 1 includes:
- Patient therapist search
- Therapist profiles
- Therapist availability
- Appointment booking
- Patient appointments
- Therapist dashboard
- Therapist appointment details
Do not rebuild or remove these existing features.
For this task, focus ONLY on making Authentication and User Roles
production-ready. Do not add Stage 2 clinical-record features.
1. Primary Goal
Replace any demo, hard-coded, or simulated login/role switching with a
proper authentication and authorization system using Base44's supported
native authentication capabilities.
- The system must securely distinguish between Patient and Therapist.
- The application should enforce permissions based on the authenticated
user's identity and role.
- The UI should never be the only security layer.
2. User Authentication
Provide separate signup paths: "I'm a Patient" and "I'm a Therapist."
Patient signup fields:
- Full name
- Email
- Password
- Confirm password
- Phone number
- Agree to Terms of Service and Privacy Policy
Therapist signup adds:
- Professional title
Do not collect unnecessary clinical information during signup.
3. Login
Fields: email, password.
Include: Log In, Forgot Password, Create Account.
After successful authentication:
- Patients redirect to Find a Therapist
- Therapists redirect to Therapist Dashboard
Do not allow users to manually select a role after logging in; the role
comes from the authenticated account.
4. Email Verification
Implement email verification if supported by Base44's authentication
system. New users should verify their email before accessing protected
functionality.
Handle:
- Verification email
- Success
- Failure
- Expired link
- Resend
Use Base44's native implementation rather than a custom one.
5. Password Security
Use Base44's native secure password handling.
Do NOT:
- Store passwords in custom database fields
- Store plaintext passwords
- Expose passwords through frontend code
- Create a custom password system if Base44 already provides one
Implement:
- Password reset
- Secure handling
- Confirmation during signup
- Protection against repeated failed login attempts where supported
6. Forgot Password
Flow: Forgot Password → Enter Email → Reset Link → New Password → Login
Do not reveal whether an email belongs to an existing account. Use a
generic response like "If an account exists for this email, we'll send
you instructions to reset your password."
7. User Data Model
Use Base44 authentication as the source of truth for identity.
User Profile fields:
- id, auth_user_id, full_name, email, phone, role, profile_image,
account_status, email_verified, created_at, updated_at
Role values: patient, therapist
Account status values: active, suspended, deactivated
Do not duplicate authentication credentials into the application
database.
8. Role Assignment
- Patient signup → patient
- Therapist signup → therapist
Users must NOT be able to change their role from the frontend, through a
form, URL parameter, API request, or dev tools. Do not create a public
role-change feature.
9. Route Protection
Public routes:
- Landing page
- Login
- Patient/therapist signup
- Password reset
- Email verification
- Public therapist discovery/profiles
Patient-only routes:
- Patient dashboard
- My Appointments
- Patient profile
- Booking actions
Therapist-only routes:
- Therapist dashboard
- Therapist appointments
- Therapist patient/appointment information
- Therapist profile management
10. Server-Side Authorization
Do NOT rely only on frontend route protection. Every protected
backend/database operation must verify:
- The user is authenticated
- The account is active
- The role allows the requested action
- The requested record belongs to or is associated with that user
A patient must NOT be able to request another patient's appointments by
changing an appointment ID. A therapist must NOT access another
therapist's appointments by changing a therapist ID.
11. Database Security Rules
Patients can:
- Read/update their own profile
- Read their own appointments
- Create appointments for themselves
- Cancel their own eligible appointments
Patients cannot:
- Read another patient's information
- Modify another patient's appointments
- Modify therapist data
- Modify appointment ownership
- Modify their own role
Therapists can:
- Read/update their own profile
- Read their own appointments
- Update eligible appointment statuses
- Access patient information only when legitimately associated with
their appointment
Therapists cannot:
- Read another therapist's appointments
- Modify another therapist's profile
- Change appointment ownership
- Change their own role
- Access unrelated patients
12. Prevent Privilege Escalation
Explicitly test and prevent:
- A patient changing their own role to therapist (denied)
- A patient manually navigating to the therapist dashboard
(denied/redirected)
- A patient changing an appointment ID to another patient's appointment
(denied)
- A therapist changing a therapist ID to another therapist's (denied)
- An unauthenticated user accessing protected data (denied)
- A suspended user accessing the application (blocked)
13. Account Status
Support statuses: active, suspended, deactivated.
- Do not permanently delete user records simply because an account is
deactivated.
- Keep account lifecycle logic separate from authentication credentials.
14. Logout
After logout:
- End the authenticated session
- Protected pages must no longer be accessible
- Browser back-button navigation must not expose protected data
- API requests requiring authentication must fail
15. Session Handling
Use Base44's native session management. Handle:
- Expired sessions
- Invalid sessions
- Logout
- Session restoration
- Protected-route access
- Unauthorized API requests
On expiry, show an appropriate message and redirect to login without
losing unrelated unsaved information where practical. Do not implement
custom authentication tokens unless required by Base44.
16. Profile Access
Patient profile: name, email, phone, profile photo, account status,
editable by the patient.
Therapist profile: keep existing fields (name, professional title,
biography, specialties, experience, location, languages, profile photo,
appointment types) intact.
Do not introduce therapist verification yet unless it already exists.
17. Authentication UX
Consistent experience across Login, Forgot Password, Patient Signup, and
Therapist Signup pages, with clear validation messages:
- "Please enter a valid email address"
- "Password does not meet the required requirements"
- "Passwords do not match"
- "Please accept the Terms of Service and Privacy Policy"
18. Security Requirements
- Do not expose passwords, authentication tokens, secrets, or private
database credentials in frontend code.
- Do not store sensitive authentication information in localStorage
unless Base44's native implementation explicitly requires it.
- Use HTTPS/secure transport in production.
- Use secure server-side authorization for protected data.
19. Authentication Error Handling
Do not expose sensitive system information (e.g. "No user exists with
this email"). Use generic messages where account enumeration could
occur.
Handle:
- Invalid credentials
- Expired verification
- Password reset failure
- Suspended/deactivated accounts
- Expired sessions
- Unauthorized access
- Server/authentication errors
20. Preserve Existing Stage 1 Functionality
Do not break:
- Therapist search
- Filtering
- Profiles
- Availability
- Appointment booking
- Patient appointments
- Therapist dashboard
- Therapist appointment details
After implementing authentication, test the entire existing Stage 1
workflow with both roles.
21. Test With Separate Accounts
Create separate test accounts for at least one patient and one
therapist, using fictional test data only. Test that each account sees
only the functionality appropriate for its role.
22. Required Authentication Test Matrix
Test:
- Patient signup creates a patient account
- Therapist signup creates a therapist account
- Valid patient/therapist login reaches the right dashboard
- Invalid password is rejected
- Forgot password works
- Email verification works
- A patient opening a therapist route is denied
- A therapist opening a patient-only route is denied
- A patient accessing another patient's data is denied
- A therapist accessing another therapist's data is denied
- A patient or therapist modifying their role is rejected
- Logout terminates the session
- An expired session requires re-authentication
- A suspended account is blocked
- An unauthenticated API request is rejected
23. Security Testing
Do not only test the normal UI. Test authorization by attempting to
manipulate:
- URLs
- Record IDs, user IDs, therapist IDs, appointment IDs
- Role values
- API/backend requests
- Form payloads
The system should remain secure even if a user bypasses the frontend UI.
24. Do Not Build Yet
This task is ONLY for Authentication + User Roles + Authorization. Do
NOT add:
- Clinical records, intake forms, diagnoses, treatment plans, session
notes, assessments
- Prescriptions, medication management
- Telehealth, payments, insurance
- AI features, messaging
- Advanced admin features
- A therapist verification workflow
Those belong to later stages.
25. Final Acceptance Criteria
Authentication:
- Real patient and therapist signup work
- Login/logout work
- Password reset works
- Email verification works where supported
- Sessions are securely managed
Authorization:
- Every protected route is role-aware
- Backend/database permissions enforce ownership
- Patients cannot access therapist-only functionality and vice versa
- Users cannot modify their own roles or access another user's records
by manipulating IDs
Existing MVP:
- Patient: Login → Search Therapist → View Profile → Book Appointment →
View Appointment
- Therapist: Login → Open Dashboard → View Appointment → View Associated
Patient Information → Update Appointment Status
Do not consider the feature complete until these workflows pass after
the authentication changes.
IMPORTANT IMPLEMENTATION RULE
- Use Base44's native authentication and authorization capabilities
wherever possible.
- Do not create a custom authentication system unnecessarily.
- Before changing the existing database structure, inspect the current
application and reuse existing User, Patient, Therapist, and
Appointment entities where appropriate.
- Avoid duplicating users or creating multiple competing sources of
truth for identity.
- Make the smallest necessary database/schema changes to support secure
authentication and role-based access.
- Prioritize security, authorization, data isolation, and reliability
over visual changes.
After implementation, provide a concise report of:
- What authentication features were implemented
- What role/permission rules were implemented
- What database security rules were added/changed
- What existing Stage 1 functionality was tested
- Any Base44 limitations that prevent a requirement from being fully
enforcedStep 3: Expect Real Bugs in the Auth Flow
Adding authentication and Base44 role-based access surfaced an edge case the MVP never hit: signing up through Google led to an “access denied” screen, because no role had been selected at account creation.
The fix used the same habit from Part 1: describe the problem to Base44 precisely and let it resolve it. The corrected flow sends a new Google user to a short step to pick Patient or Therapist, rather than an error state.
Email verification also worked end to end, with a real verification email arriving after sign-up.
In a live product, this is the kind of bug that costs you users quietly. Someone who signs up and lands on “access denied” rarely reports it. They just leave. Test every sign-up path, not only the one you use yourself.
Step 4: Decide Whether to Stay in Base44 or Export
For a healthcare app, this decision comes down to control. Most of HIPAA’s technical safeguards apply where data is stored and processed: the backend and database. That’s exactly the layer you have the least control over on a vendor-managed platform (more in Part 3).
Staying in Base44: the app can go live on a free base44.app address without touching infrastructure, and a custom domain (available on paid plans) can be purchased and connected through the platform itself. In the Base44 editor’s left sidebar, that’s under Domains:
It’s the fastest way to deploy AI apps with Base44, but the backend and database stay outside your control. Base44’s terms also bar protected health information without its prior written agreement, so for a healthcare app that will handle real patient data, staying on Base44 is a path for prototypes and demos, not production.
Exporting for self-managed production: export requires a paid Base44 plan. Base44 exports:
- The frontend
- Any backend functions
It doesn’t export the authentication system, database, or hosting. In practice, the exported React app still points at Base44’s remote backend URLs, and replacing those URLs with your own services is the Base44 backend replacement that Steps 5 and 6 walk through.
If you plan to add HIPAA-oriented logging, it can be done in Base44 before exporting; Part 3 covers that.
The export lives under the “…” menu in the top-right corner of the editor, not the sidebar. It opens to GitHub connection and Export project as ZIP:
That same menu’s This page’s files option lets you browse the React code behind whichever page you’re on, inside Base44 itself.
Each entry shows a file name with its folder underneath: FindTherapist.jsx in src/pages, and UI components like button.jsx, input.jsx, and label.jsx in src/components/ui. These are the same frontend files the export gives you:
What the Choice Really Costs
Staying on Base44 is faster and cheaper up front, but you’re renting the backend:
- You can’t change how data is stored
- You depend on Base44’s plans and pricing
- Real patient data is off the table without Base44’s written agreement
Exporting takes more work up front and leaves you responsible for a backend. In return, the code and the data become something you own and control.
That matters beyond compliance. A product running on infrastructure you control is easier to explain to:
- Investors
- A buyer during due diligence
- The clinics deciding whether to trust you with their patients
A practical rule: stay on Base44 while you’re still validating the idea with fictional data, and plan the export before the first real patient signs up.
Weighing whether to stay on Base44 or rebuild the backend? Technology Rivers helps healthcare teams plan the move from an AI-built prototype to infrastructure they control. Talk to us about your migration path
Step 5: Generate the Backend
When you export to deploy AI apps with Base44 outside its hosting, this is the step that does the heaviest lifting. Once you’ve exported the frontend, it still depends on Base44’s authentication and database, which don’t come with it.
The new backend gets built outside Base44 entirely, in an AI coding assistant like Codex, Claude Code, or Cursor.
The prompt started the same way as in Step 2, with a short, plain request to ChatGPT describing the situation:
I have created a Base44 app and downloaded its code for local use and
custom production deployment. However, I only received the UI/frontend
code, while its APIs are hosted on Base44 and cannot be altered locally.
Now I want to create the backend along with the database configuration
using Codex or Claude Code. Give me a detailed prompt that can help
build the complete working app according to the existing frontend.The prompt matters as much here as it did inside Base44. Asking a coding assistant to simply “build a backend for MindCare” risks APIs that don’t match the frontend.
The prompt below treats the exported frontend as the source of truth instead. These are its key sections.
Inspect the frontend before writing any backend code
A backend built on assumptions won’t match the APIs the frontend actually calls:
Build the Complete Production Backend for the Existing MindCare Frontend
ROLE
You are a senior full-stack architect and backend engineer.
The downloaded repository currently contains primarily the frontend/UI
code, while the original application depended on Base44-hosted
APIs/backend services. The existing frontend is the source of truth for
the current UI and user experience.
1. CRITICAL RULE: INSPECT BEFORE IMPLEMENTING
Before writing backend code, thoroughly inspect the existing repository.
Do NOT immediately start creating a new backend based on assumptions.
First analyze:
- Directory structure, package manager, package.json, framework
- React components, routes, pages, hooks, context providers
- Services, API clients, fetch/axios calls
- Base44 SDK usage and any references to Base44-specific services
- Authentication implementation and environment variables
- Forms, validation, state management
- Appointment, therapist, patient, and availability logic
- Any mock/demo or hard-coded data
Also inspect all frontend forms and actions to determine exactly what
data the backend must accept and return.Block double-booking at the database, not the button
Two patients clicking the same slot at the same moment is a real scenario, so booking has to be transactional:
13. DOUBLE-BOOKING PROTECTION
Appointment booking must be concurrency-safe. If Patient A and Patient B
both see 3:00 PM as available and click Book simultaneously, only one
booking may succeed.
Implement transactional booking logic. The operation should:
- Start a transaction
- Lock/check the availability slot
- Verify it is still available
- Create the appointment
- Mark/reserve the availability
- Commit the transaction
If the slot is already booked, return 409 Conflict with a user-safe
message:
"This appointment slot is no longer available."Check ownership on every request
The rule from Step 2 carries over to the new backend: the server decides who can see what, not the frontend.
24. SERVER-SIDE AUTHORIZATION
This is mandatory. Do not rely on frontend route protection.
Every protected endpoint must verify:
- Authentication
- Account status
- Role
- Resource ownership/relationship
- Action permission
GET /appointments/123 must not simply query appointment.id = 123. It
must additionally verify that the authenticated user is authorized to
access that appointment.
25. PATIENT DATA ISOLATION
Patient A must never be able to access Patient B's appointment by
changing appointment_id or any URL/query/body parameter. Therapist A
must not be able to access Therapist B's patients simply by changing
therapist_id.
Implement authorization in the service/repository layer.Finish with zero runtime calls to Base44
The point of the migration is independence, so the prompt defines “done” as the app working with Base44 switched off:
35. DO NOT USE BASE44 AS THE BACKEND
The purpose of this migration is to remove the application's runtime
dependency on Base44 APIs.
- Find every Base44 API dependency in the frontend.
- Replace it with the corresponding local backend API.
- The final application should work when Base44 is completely
unavailable.
- There should be no required runtime request to Base44.
After migration, verify this by searching the entire codebase for Base44
references.Two more sections cover the frontend and the stack. Click to expand them.
▶ Click to view the frontend and stack sections
3. DO NOT BREAK THE EXISTING FRONTEND
The existing frontend already represents the intended Stage 1 product.
Preserve:
- Existing pages, navigation, and visual design
- Existing forms
- Existing therapist search and therapist profiles
- Existing availability UI and booking flow
- Existing patient appointments
- Existing therapist dashboard and appointment details
The goal is:
Existing frontend + new backend = working application
Do not redesign the product unless a change is technically necessary. If
a frontend change is required, make the smallest possible change.
4. RECOMMENDED BACKEND STACK
Unless the repository or deployment requirements strongly indicate
otherwise, use:
- Backend: Node.js + TypeScript
- Framework: Fastify, or another mature REST framework if the repository
already has a strong convention
- Database: PostgreSQL
- ORM: Prisma
- API: REST, base URL /api/v1
- Validation: Zod
- Password hashing: Argon2id, if implementing password-based
authentication ourselves
- Testing: unit, integration, and API tests
- Local infrastructure: Docker ComposeThe result is a local API server the exported frontend points at through its environment variables, tested against the same core flows from Part 1: search, book, and view the dashboard.
Exporting also changes who owns the work after launch. The backend is now your code, so every bug fix, security patch, and dependency update is yours to make, or your development partner’s. Plan for that maintenance from the start, not after the first incident.
Step 6: Recreate the Database Structure
Base44 exports individual table schemas and table data, but not a full database dump or its configuration.
The other half of the Base44 backend replacement is recreating the database from those exports. Here’s what the data view looks like inside Base44, with the Patient table open:
Open each table (Patient, Therapist, Appointment, and Availability, plus AuditLog if you’ve already added audit logging, covered in Part 3) from the Data section in the sidebar and export its schema and data.
User accounts live under App Users, which is part of Base44’s authentication system, so the new backend rebuilds those itself.
The backend prompt from Step 5 then turns those entity definitions into a PostgreSQL schema with Prisma migrations and seed data. The prompt spells out what a clean setup has to look like:
33. DATABASE MIGRATIONS
Use Prisma migrations. The repository should contain:
- prisma/schema.prisma
- prisma/migrations/
- prisma/seed.ts
The database must be reproducible from a clean installation. A new
developer should be able to:
- Start PostgreSQL
- Install dependencies
- Run migrations
- Run seed
- Start backend
- Start frontend
- Use the applicationOnce the frontend, backend, and database are connected, the whole system should run locally with no calls to Base44, which is the last checkpoint before deployment.
Step 7: Deploy AI Apps with Base44 on Your Own Infrastructure
With the frontend, backend, and database running together outside Base44, the next step is containers. The backend prompt covers the backend image and local setup:
48. DOCKER
Create a production-capable backend Dockerfile.
Also create a local docker-compose.yml with PostgreSQL. The development
environment should allow:
docker compose up
to start required infrastructure. Document how to run migrations.Build Docker images for both the frontend and the backend so the whole system runs in isolated containers. The frontend image keeps local and staging setups consistent; in production, the built frontend is usually served as static files.
From there, here’s a standard self-managed AWS shape for Base44 production deployment:
- Push the images to a container registry (AWS ECR)
- Run the backend container on a managed compute service (ECS) behind a load balancer (ALB)
- Serve the built frontend as static files from S3, with CloudFront in front of it
- Run the database on a managed service (RDS)
- Point your custom domain at CloudFront for the app, and an API subdomain at the load balancer
A simpler, older alternative to containers is running the backend directly on a single EC2 instance. It works, but it’s generally less resilient than the container-based approach.
The cloud provider itself (AWS, Azure, Google Cloud) is a business decision independent of this cloud architecture; the shape above applies across providers.
Let your customers guide that choice. If you plan to sell to clinics or health systems, find out which cloud providers they already approve. Then confirm the provider will sign a BAA covering the specific services you plan to use, before any patient data lands there.
Where Technology Rivers Comes In
By Step 4, the work stops being prompting and starts being engineering. The prototype works and the export is possible, but someone still has to:
- Build the backend
- Design the database
- Set up the infrastructure
- Own all of it after launch
Technology Rivers takes on that work for healthcare teams moving off Base44 and similar AI tools:
- Reviewing the exported code to decide what to keep and what to rebuild
- Building the backend and database the exported frontend depends on
- Setting up cloud infrastructure with access controls, logging, and BAA-covered services
- Testing the full patient and therapist flows before real users arrive
- Maintaining and extending the app after launch
You keep the product decisions. We handle the engineering that turns a working prototype into something you can run.
Frequently Asked Questions
Can I export my Base44 app’s code?
Yes, on a paid plan. Open your app in the Base44 editor, click the three-dot menu (⋯) in the top-right corner, and choose Export project as ZIP to download the code or GitHub connection to sync it to a repository. You get the React frontend and any backend functions, not a complete working copy of the app, so check what’s missing before you plan a move.
Does a Base44 export include the backend and database?
No. The export leaves out Base44’s authentication system, database, and hosting, so the exported app still sends every login and data request to Base44’s servers. To run it on your own, you need a replacement backend and a new database rebuilt from Base44’s table exports. That usually means building an API and a database such as PostgreSQL, often with the help of an AI coding assistant.
Can I use a custom domain with Base44?
Yes, on a paid plan. In the editor’s left sidebar, open Domains, then buy a domain through Base44 or connect one you already own. On the free plan, your app still goes live, just at a base44.app address. A custom domain only changes the address. Your backend and data still run on Base44.
What happens to my published app if I downgrade my plan?
The downgrade takes effect at the end of your billing period, and your app stays published. What can break are the paid features it depends on, such as a custom domain or GitHub sync. Before you downgrade, list the paid features your app uses and check which ones the lower plan still includes.
Is Base44 good enough for a production app?
It depends on the data. For an internal tool or an app with no sensitive data, Base44 can host a live app with real users. For a healthcare app with real patient data, not without Base44’s written agreement, because its terms bar protected health information otherwise and it doesn’t offer a BAA on its plans. For that kind of app, exporting to infrastructure you control is the safer path.
Continue the Series
In Part 3, the focus shifts from production readiness to compliance and security hardening: encryption, audit logging, and the infrastructure protections needed to move MindCare closer to HIPAA readiness.
None of the steps above make MindCare HIPAA compliant on their own. Before compliance work starts, anyone planning to deploy AI apps with Base44 needs real authentication, enforced roles, and a clear path to infrastructure they control, which is what this post covered.
Ready to move your Base44 app from prototype to production? Request a consultation to discuss architecture, infrastructure, and deployment strategy.
This post describes a prototype built with fictional data and is not legal advice. Consult a qualified advisor about the HIPAA obligations for your own application, and confirm Business Associate Agreement (BAA) coverage with any third-party tool or service before it handles protected health information.
