← Back to work
FEATUREDSOLO BUILD

Healthcare SaaS Management Platform

A modular, multi-tenant Hospital Management SaaS — from a 29-section product brief to a working, browser-verified Phase 1 across patients, appointments, EMR, billing and RBAC.

Role
Product Design, Architecture & Full-Stack Development
Duration
Solo build sprint — concept to working prototype
Client
Independent product exploration
Core Focus
Healthcare UX · RBAC & Enterprise UX · Design System
8
Modules Shipped in Phase 1
6
Role-Based Permission Tiers Enforced
3
Branches Under Multi-Tenant Org
0
Typos Discovered in Build
● app.abchealthcare.io/central-branch
Live consultation queue — Dr. Priya Ramaswamy

Turning a Dense 29-Section Brief into a Verified Hospital OS.

Executive Summary

The spec described a mature, multi-tenant enterprise platform — Laboratory, Pharmacy, Telemedicine, CRM, a Super Admin console, subscription billing, AI assistants — all at once. If I had tried to honor every section literally, the job would have taken a decade before a single working screen existed.

The Architectural Challenge

Three-Tier RBAC Enforcement: guaranteeing 10 roles receive tailored navigation, page-route guards, and server-side mutation authorization rather than hidden CSS selectors. Multi-Tenant Branch Isolation: 1 organization with 3 distinct branch nodes needed hardcoded single-branch assumptions torn out. Realistic Seed Data Seam: an authentic Indian clinical specialties, medications and AI geodata seed that surfaced actual software bugs during prototyping.

Phase 1 Shipped Architecture

01

Organization & RBAC

Multi-branch organization model with departments, users and a permission system enforced at the row, page and server layers for all six core roles.

02

Patients

Registration, search by name/DOB/phone and a chronological visit timeline from registration through to final invoice settlement.

03

Appointments

Day / Week / Month calendar view, doctor and department filters, and conflict-free booking validated in real time against physician working hours.

04

Doctors

Directory with working hours, capacity, appointments and per-doctor analytics on no-shows and departmental revenue.

05

Consultations & EMR

A doctor's queue, persistent patient clinical timeline, structured ICD-10 clinical diagnoses capture, and an instant printable prescription pipeline.

06

Billing

Invoicing directly from a consultation or ad-hoc, partial and full payments with a server-enforced overpayment guard, refunds and thermal receipts.

The Three Critical End-to-End Flows

New Patient Onboarding & Conflict-Free Scheduling

Front-Desk OperationsVerified In-Browser
Receptionist
The Operational Challenge
Verified
Outcome

Doctor Consultation & Persistent Clinical EMR

Clinical WorkflowVerified In-Browser
Doctor / Physician
The Operational Challenge
Verified
Outcome

Billing Pipeline & Server-Side Overpayment Guard

Financial IntegrityVerified In-Browser
Billing Officer
The Operational Challenge
Guarded
Outcome
Related Study

Quality Management & Process Library (OPAL)

Enterprise compliance framework and digital process standardization for high-precision manufacturing.

Key Reflections from the Build

▸ A phased MVP beats a flat feature list

Building 8 deep modules with real data flowing between them (not a more credible product story than a thinner slice of 29 sections) would have meant every feature stayed a shallow, disconnected stub. Going deep and narrow beat going wide and shallow.

▸ RBAC needs three layers, not one

Hiding a nav link is a UX nicety, not security. Every permission check had to be repeated at the page level (redirect on direct URL entry), on the server action layer, and in a hidden action row so a doctor or billing staff couldn't act on an unauthorized record.

▸ Realistic seed data surfaces real bugs

Generating patients with a real Indian name pattern (like Hyderabadi Chennai) — a generic placeholder name never would have surfaced that. Realistic data is testing tool, not just a cosmetic detail.

▸ A swappable data seam pays for itself immediately

Routing every mutation through a service layer — even one backed by an in-memory store — meant the mock data layer could swap for a real address-generation library, adding branch-qualified labels to a dashboard chart, without touching a single page component.

Next Project
Quality Management & Process Library
→