How to Build a Production-Ready HIPAA-Compliant App with Lovable (Vibe Coding Guide)

In the first three parts of this series, we covered how to build an AI app with Lovable, make it production-ready, and secure it for HIPAA compliance. Each step improved the application, but the approach required going back and retrofitting architecture, security, and compliance into an already generated codebase. That is not how production systems should be built.

In real-world AI app development, especially in healthcare, these requirements must be defined from the start. In our experience working with AI-driven healthcare applications, the biggest challenges rarely come from generating code — they come from making that code secure, compliant, and scalable in real-world environments.

Teams facing that challenge usually need more than faster generation. They need the right delivery model, secure architecture, and healthcare-specific technical planning, which is why our healthcare app development and AI and machine learning services are built for real-world product execution.

This is Part 4 of our Lovable series. We also cover the full journey from initial build to production-ready, HIPAA-compliant applications in the other parts of this guide:

• From AI Prototype to Production: How to Build Scalable AI Applications (Lovable Guide)
• From AI Prototype to Production: How to Build Scalable AI Applications (Lovable Guide)
• How to Make a Lovable App HIPAA Compliant (Step-by-Step for Vibe Coding Apps)

This guide takes a different approach. It shows how to build a production-ready HIPAA compliant AI app using Lovable by combining architecture, security, and compliance into a single prompt.

Why Building Everything Upfront Matters

Most AI-generated apps fail at scale because they are built incrementally. They lack:

• Audit logging
• Secure backend architecture
• PHI protection
• Scalable design

Retrofitting these later introduces:

• Technical debt
• Security risks
• Compliance gaps

By defining everything upfront, you generate a system that is:

• Scalable from day one
• Secure by design
• Compliance-ready

Step 1: How the Master Prompt Was Built

The master prompt combines all previous stages into a single instruction set. It includes:

• Application scope (from Part 1)
• Production architecture (from Part 2)
• HIPAA compliance controls (from Part 3)

But it also introduces critical enhancements.

Key Enhancements in the Master Prompt

1. Full Audit Logging from Day One

A database_audit_logs table is defined upfront. It includes:

• before_record_state
• after_record_state

This enables:

• Full history tracking
• Record versioning
• Compliance audit readiness

2. PHI-Specific Activity Tracking

New events are added:

• phi_record_viewed
• phi_record_updated
• phi_record_deleted

This ensures:

• PHI access is tracked
• Compliance requirements are met

3. Contextual Audit Data

Both activity and audit logs now include:

• ip_address
• user_agent

This provides:

• Traceability
• Context for security investigations

Step 2: The Master Prompt (Production + HIPAA Ready)

Paste the entire prompt below into the Lovable project description field. When Lovable prompts you to enable cloud services, accept the option. Cloud services connect the app to a real managed database and run on a pay-as-you-go model.

Master Prompt — Production-Ready HIPAA-Compliant User Management App

Build a full-stack, production-style, HIPAA-compliant User Management web
application with a modern, sleek SaaS-style UI. This application must be
built production-ready and HIPAA-compliant from the start.

========================
TECH STACK
========================
Frontend:
- React (latest version)
- Tailwind CSS
- Axios
- React Router

Backend:
- Node.js (Express preferred)
- JWT-based authentication and authorisation
- bcrypt for password hashing
- AES-256 for field-level encryption
- Helmet.js for secure HTTP headers
- express-rate-limit for rate limiting
- express-validator for input sanitisation

Architecture:
- Clean modular architecture
- Separation of concerns (pages, components, services, API layer)
- Reusable components
- Scalable folder structure
- Cloud-function-friendly backend (see section below)

========================
APPLICATION SCOPE
========================
Create a 2-page application:

1. USER LISTING PAGE
- Display users in a modern, sleek UI (table-based)
- Show: full name, email, phone number, role, status
- Each row must be clickable
- On click -> navigate to User Profile page
- Include search functionality (name or email)
- Include loading and empty states
- Skeleton loader rows during fetch
- Error state: show 'Unable to load users. Please try again.' if API fails
- Pagination if users exceed 10 per page
- Fully responsive

Track events:
- user_viewed_user_list
- user_clicked_user_profile
- user_searched_users

2. USER PROFILE PAGE
- Display full user details
- Allow: create new user, update existing user
- Fields:
  first_name, last_name, email_address, phone_number,
  user_role, user_status, address, profile_notes, profile photo
- Dropdowns: user_role (Admin, Manager, User)
  user_status (Active, Inactive, Suspended)
- Two-column layout on desktop, one column on mobile
- Form validation on all required fields
- Disabled Save button while saving, loading spinner on submit
- Success toast: 'User updated successfully'
- Redirect back to /users after save
- Cancel button returns to user list without saving
- Include validation
- Show success/error states

Track events:
- user_viewed_user_profile
- user_created_new_profile
- user_updated_user_profile

========================
DESIGN REQUIREMENTS
========================
- Modern SaaS dashboard feel
- Minimal and sleek design
- Tailwind-based UI
- Soft shadows, rounded corners
- Clean typography
- Proper spacing
- Simple top navbar
- Smooth UX
- Status badge colours: Active -> Green, Inactive -> Gray, Suspended -> Red

========================
BACKEND REQUIREMENTS
========================
Build REST APIs:
- GET /api/users
- GET /api/users/:id
- POST /api/users
- PUT /api/users/:id
- POST /api/user-activity
- Add validation on all incoming request data
- Add proper error handling
- Keep controllers thin — only handle request/response
- Keep logic modular and scalable in service modules
- Log to database_audit_logs on every INSERT, UPDATE, DELETE
- Log to user_activity on every significant user action

========================
CLOUD-FUNCTION-FRIENDLY ARCHITECTURE
========================
- Keep business logic separate from route handlers
- Controllers should only handle request/response
- Implement core logic in reusable service modules
- Do not tightly couple logic with Express or HTTP objects
- Services receive plain inputs and return plain outputs
- Ensure logic can be reused in:
  local server
  production server
  serverless/cloud functions (AWS Lambda, GCP, Azure Functions)
- Design in a way that APIs can later wrap these functions easily
  without refactoring

Follow this pattern everywhere:
  // services/userService.js <-- pure business logic, no Express
  async function createUser(userData) { ... }

  // controllers/userController.js <-- only HTTP concern
  async function handleCreateUser(req, res) {
    const result = await userService.createUser(req.body);
    res.status(201).json(result);
  }

========================
ROLE-BASED ACCESS CONTROL (RBAC)
========================
- Every API request must include a JWT token in the Authorization header
- A middleware function reads user_role from the JWT payload on every request
- Routes that access PHI data are restricted to roles: admin and clinician
- Any unauthorised access returns HTTP 403 with a structured error response
- The RBAC middleware must be a standalone module in /middleware/auth.js
- Log every unauthorised access attempt to user_activity as
  unauthorized_access_attempt

========================
FIELD-LEVEL ENCRYPTION FOR PHI
========================
The following fields in application_users contain PHI and MUST be encrypted
at rest using AES-256 before writing to the database:
- email_address
- phone_number
- address
- profile_notes
- Encryption and decryption happen only inside the service layer (/services/)
- The UI always receives and sends plaintext
- The encryption key is read from the environment variable PHI_ENCRYPTION_KEY
  — never hardcoded
- All API communication uses HTTPS
- Session tokens use secure and httpOnly cookie flags
- Build a standalone encryptionService.js in /services/

========================
AUTOMATIC SESSION TIMEOUT
========================
- Implement a 15-minute inactivity timeout on the frontend
- Track user activity via mouse movement, keypress, and click event listeners
- At 14 minutes of inactivity, show a warning modal:
  'Your session is about to expire. Stay logged in?'
- If no response within 60 seconds, clear the JWT token from storage,
  log session_expired_inactivity to user_activity, and redirect to /login
- The warning modal must have a 'Stay Logged In' button that resets the timer
- Implement as a reusable hook: useSessionTimeout

========================
SECURITY MIDDLEWARE (APPLY GLOBALLY)
========================
- Helmet.js — sets secure HTTP headers
- Rate Limiting — max 100 requests per 15 minutes per IP
- Input Sanitisation — strip and validate all inputs on POST and PUT routes
- CORS — restrict origins to allowed domains only (from ALLOWED_ORIGINS env var)

========================
DATABASE RULES (STRICT)
========================
Every table MUST include:
- created_at
- created_by
- updated_at
- updated_by
- deleted_at
- deleted_by

Naming conventions:
- snake_case ONLY
- highly descriptive table and column names
- All reference tables must start with ref_
- Soft deletes only — never hard-delete records.
  Set deleted_at and deleted_by instead.

========================
DATABASE TABLES
========================
Table: application_users
- application_user_id UUID PRIMARY KEY DEFAULT gen_random_uuid()
- first_name VARCHAR(100) NOT NULL
- last_name VARCHAR(100) NOT NULL
- email_address TEXT NOT NULL UNIQUE -- PHI: encrypted at rest
- phone_number VARCHAR(50) -- PHI: encrypted at rest
- address TEXT -- PHI: encrypted at rest
- profile_notes TEXT -- PHI: encrypted at rest
- user_role VARCHAR(50) NOT NULL
- user_status VARCHAR(50) NOT NULL
- profile_photo_url TEXT
- password_hash TEXT NOT NULL
- created_at, created_by, updated_at, updated_by, deleted_at, deleted_by

Table: user_activity
Tracks every meaningful user action. Include ip_address and user_agent.
- user_activity_id UUID PRIMARY KEY DEFAULT gen_random_uuid()
- application_user_id UUID REFERENCES application_users
- activity_event_type VARCHAR(100) NOT NULL
- activity_event_description TEXT
- activity_metadata JSONB
- activity_occurred_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW()
- ip_address VARCHAR(45)
- user_agent TEXT
- created_at, created_by, updated_at, updated_by, deleted_at, deleted_by

Table: database_audit_logs
Records every INSERT, UPDATE, and DELETE across all tables.
Provides full history and versioning. This table is append-only.
- database_audit_log_id UUID PRIMARY KEY DEFAULT gen_random_uuid()
- audit_target_table_name VARCHAR(100) NOT NULL
- audit_operation_type VARCHAR(10) NOT NULL -- INSERT, UPDATE, DELETE
- audit_record_id UUID NOT NULL
- acting_user_id UUID REFERENCES application_users
- acting_user_role VARCHAR(50)
- before_record_state JSONB -- full snapshot BEFORE operation (null for INSERT)
- after_record_state JSONB -- full snapshot AFTER operation (null for DELETE)
- changed_field_names TEXT[] -- columns that changed (UPDATE only)
- audit_occurred_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW()
- ip_address VARCHAR(45)
- user_agent TEXT
- created_at, created_by, updated_at, updated_by, deleted_at, deleted_by

Audit logging rules:
- For UPDATE: fetch record first (before_record_state), write the update,
  then log both states and list changed fields in changed_field_names
- For DELETE: capture before_record_state before soft-deleting
- For INSERT: populate only after_record_state
- Build a standalone auditLogService.js in /services/
- No updates or deletes are ever permitted on database_audit_logs

========================
USER ACTIVITY TRACKING
========================
Track events such as:
- user_logged_in
- user_logged_out
- user_viewed_user_list
- user_clicked_user_profile
- user_searched_users
- user_viewed_user_profile
- user_created_new_profile
- user_updated_user_profile
- phi_record_viewed (log every time a PHI record is accessed;
  include which application_user_id was viewed)
- phi_record_updated (log every update to PHI fields;
  include which fields changed)
- phi_record_deleted (log every soft delete of a PHI record)
- unauthorized_access_attempt
- session_expired_inactivity

========================
FOLDER STRUCTURE
========================
/
├── frontend/
│   ├── src/
│   │   ├── components/
│   │   │   ├── UserTable/
│   │   │   ├── UserRow/
│   │   │   ├── UserForm/
│   │   │   ├── AvatarUpload/
│   │   │   ├── StatusBadge/
│   │   │   ├── SessionTimeoutModal/
│   │   │   └── SkeletonLoader/
│   │   ├── pages/
│   │   │   ├── UsersList/
│   │   │   └── EditUser/
│   │   ├── services/
│   │   │   └── api.js
│   │   ├── hooks/
│   │   │   ├── useUsers.js
│   │   │   └── useSessionTimeout.js
│   │   └── router/
│   │       └── routes.js
│   └── Dockerfile
│
├── backend/
│   ├── src/
│   │   ├── controllers/
│   │   │   ├── userController.js
│   │   │   └── activityController.js
│   │   ├── services/
│   │   │   ├── userService.js
│   │   │   ├── activityService.js
│   │   │   ├── auditLogService.js
│   │   │   └── encryptionService.js
│   │   ├── middleware/
│   │   │   ├── auth.js
│   │   │   ├── rateLimiter.js
│   │   │   └── sanitize.js
│   │   ├── routes/
│   │   │   ├── userRoutes.js
│   │   │   └── activityRoutes.js
│   │   └── db/
│   │       ├── schema.sql
│   │       └── seed.sql
│   ├── .env.example
│   └── Dockerfile
│
└── docker-compose.yml

========================
DOCKER SETUP
========================
Generate Dockerfiles for both frontend and backend so the full stack
can run locally with a single command.
- Frontend Dockerfile: multi-stage build, build React app, serve with nginx
- Backend Dockerfile: Node.js slim image, expose API port
- docker-compose.yml must wire together:
  frontend service (port 3000)
  backend service (port 4000)
  db service using PostgreSQL (port 5432)
  shared environment variables via .env file
- Running docker-compose up should start the full application
  with no additional configuration

========================
DELIVERABLES
========================
- Full frontend (React + Tailwind)
- Full backend (Node.js)
- Database schema (all three tables)
- Sample seed data (at least 15 users across all roles and statuses)
- API integration (frontend <-> backend)
- Clean folder structure as specified above
- Activity tracking implementation
- Dockerfiles and docker-compose.yml
- .env.example file

========================
IMPORTANT
========================
- Do NOT over-engineer
- Prioritize readability and clarity
- Follow naming conventions strictly
- The database_audit_logs table is append-only — never modified after insert
- Soft deletes only — never hard-delete any record in any table
- PHI fields are always encrypted before hitting the database,
  always decrypted at the service layer before returning to the API
- Make it feel like a real SaaS product

In practice, this is where most AI healthcare applications fail. Moving from a generated prototype to a production-ready system requires strong architectural decisions, security planning, and compliance awareness from the start. See how we help teams design and build HIPAA-compliant AI applications that scale beyond prototypes.

Step 3: Generate the Application

The process remains simple:

• Paste the master prompt
• Enable cloud services
• Let Lovable generate the app

Within minutes, you get:

• Frontend (React + Tailwind)
• Backend (Node.js)
• Database schema
• Security controls
• Docker configuration

What Gets Generated (End-to-End System)

This is not a prototype. This is a full system.

User Interface

• User listing page with search, pagination, and error states
• User profile page with validation and responsive layout
• Session timeout modal with inactivity tracking

Backend Architecture

• Thin controllers with modular services
• JWT-based authentication and RBAC
• Encryption service for PHI
• Audit logging service capturing full record history

Database Design

• application_users table with encrypted PHI fields
• user_activity table with detailed tracking
• database_audit_logs table with full versioning

Infrastructure

• Dockerfiles for frontend and backend
• docker-compose setup
• Environment variable configuration

Step 4: Export and Take Ownership

Once generated:

• Connect to GitHub
• Export the codebase
• Clone locally

You now own:

• The full application
• Backend architecture
• Security implementation

Step 5: Generate a Secure PHI Encryption Key

HIPAA requires strong encryption. Generate a secure key using one of the following options:

Option 1 — Node.js:

node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

Option 2 — OpenSSL:

openssl rand -hex 32

Important:

• Never hardcode the key
• Never commit it to Git
• Store it securely

Step 6: Run the Application with Docker

Because Docker is included, getting the full stack running locally is straightforward:

cp .env.example .env
docker-compose up

You now have:

• Frontend → localhost:3000
• Backend → localhost:4000

This ensures consistency across environments and supports containerized AI deployment.

Important Limitation (Critical)

Lovable does NOT sign a Business Associate Agreement (BAA). This means you cannot use Lovable-hosted environments for production HIPAA apps. You must:

• Export the app
• Deploy on HIPAA-compliant infrastructure
• Use vendors that support BAA

Real-World Perspective

At Technology Rivers, we often see teams build fast with AI tools but struggle later with:

• Missing audit logs
• Weak access control
• Unsecured PHI
• Poor backend architecture

By implementing production-ready architecture upfront, these issues are avoided entirely. This approach reduces:

• Rework
• Compliance risk
• Time to production

Wrapping It Up

This tutorial shows that you don’t need multiple iterations to reach a production-ready system. With the right prompt, you can generate:

• A scalable architecture
• A secure backend
• HIPAA-compliant data handling
• Full auditability
• Deployment-ready infrastructure

All in one step. This is the future of AI app development with Lovable.

If you’re building an AI or healthcare application, getting architecture and compliance right from day one is critical. Speak with our experts to design a secure, scalable, and HIPAA-compliant system from day one — without costly rework later.