Web App

SIKOPI — Clinic Management System for an Independent Orthopedic Nursing Practice

An end-to-end clinic management system built for a real orthopedic nursing practice — from discovery to a production system they use daily, built with an AI-assisted (vibe coding) workflow.

FrontendFull-Stack DevelopmentAI-Assisted CodingClient ProjectHeath TechDashboard

TL;DR

SIKOPI replaces a solo orthopedic nursing practice's paper-based patient records with a real digital system — patient intake, clinical documentation, auto-generated medical letters, and reporting — built and shipped solo in a 1-week MVP sprint (plus about a month of iteration) using an AI-assisted ("vibe coding") workflow. There's no formal usability testing data behind this one — validation ran through iterative build-and-feedback cycles with the client instead. The clearest signal it worked: the client asked for a public demo to show off to their own contacts.

Role: Solo — discovery, database design, full-stack development
Tools: Lovable, Google Antigravity, Supabase, Notion
Duration: 1-week MVP, ~1 month of iteration

Context

SIKOPI (Sistem Informasi Keperawatan Ortopedi Praktik Independen) was built for a real client — an independent orthopedic nursing practice that was running entirely on manual, paper-based patient records. They needed a proper digital system: patient registration, clinical visit documentation, and generated medical letters (sick leave certificates, referral letters), without the overhead of an enterprise hospital EMR built for a much bigger operation.

🛠️

Built on React 19, TanStack Start (SSR), Supabase (PostgreSQL + Row-Level Security + Realtime), and a shadcn/ui + Radix UI + Tailwind CSS v4 design system. Project management and task tracking ran through Notion throughout the build.

This was an end-to-end engagement — I handled discovery and development myself, from the initial client conversation through to a production deployment the clinic uses today.

Problem

From the kick-off discovery conversation, the core problem was clear: the clinic managed everything — patient records, vital signs, diagnoses, medication, sick leave letters, referral letters — on paper. That meant slow retrieval, no structured history, no reporting, and manual, time-consuming document generation for every sick leave or referral letter.

INSIGHTS

💡

Paper-based operations don't scale with volume — every additional patient adds more retrieval time and repeats the same manual work, instead of getting easier as the practice grows.

💡

Without structured data, the clinic had no visibility into its own operations — no way to see patient trends, revenue, or common diagnoses to actually make decisions from.

💡

A solo practice doesn't need an enterprise EMR — it needs the fraction of features that actually apply to a one-person clinic, without the setup overhead of a system built for a much bigger operation.

💡

The same infrastructure serving internal staff can serve patients directly — self-service registration didn't need a separate system, just a second view into the same patient record.

💡

Documentation speed comes from recognition, not recall — letting staff select from a checklist of known cases is faster and more consistent than typing and remembering terminology each time.

PAIN POINTS

🚫

Finding a patient's history meant digging through paper files by hand — slow, and records could get lost or misplaced.

🚫

Every Sick Leave or Referral Letter was handwritten or typed from scratch, even though the same patient and visit data already existed somewhere on paper.

🚫

New patient registration meant the nurse collecting and typing every detail herself, on top of the clinical work — extra admin time on every single walk-in.

🚫

The system had to work away from a desk — with the practice run alongside hospital shifts, anything desktop-only would be unusable half the time.

🚫

Every patient had a paper trail but no shared identifier — no reliable way to pull up a specific patient's history without knowing exactly which physical file to search for.

Constraint

Tight deadline — the client needed a working MVP within 1 week, with the rest of the system completed over roughly a month of iteration afterward
Solo, end-to-end delivery — one person covering discovery, database design, and full-stack development. No separate UI/UX design phase — the client needed it running fast, so the interface was shaped directly through the AI-assisted build instead of being mocked up first
Built using an AI-assisted ("vibe coding") workflow: Lovable for rapid v0 prototyping to validate the idea fast, then continued in Google Antigravity (Google's agent-first AI coding platform) to build the production system
No formal usability testing was run — validation happened through iterative build-and-feedback cycles directly with the client, not through structured research or testing with end users
This is a New + Niche project (Q1): a system built from scratch, for one specific, reachable client — not a broad public product

🎯

Project classification: New + Niche (Q1) — new build, single reachable client. Research, testing, and success metrics are scoped accordingly, not benchmarked against a mass-market product.

Approach

The process ran in tight loops rather than long upfront phases, compressed to hit a working MVP within 1 week, then roughly a month of iteration to finish:

Request — initial client inquiry
Kick-off meeting — discovery of the clinic's actual problems and needs
v0 in Lovable — built a first working version immediately, skipping a dedicated design phase to validate the idea with something real rather than a spec document or mockups (at the same day)
Pulled to GitHub, continued in Google Antigravity — took the Lovable codebase, pushed it to GitHub, and continued building the production system with Antigravity's agent-first workflow (planning, writing, and self-testing code)
Delivered to client
Client feedback
Revision loop — repeated steps until the system matched what the clinic actually needed

Solution

Patient management

Searchable patient list with auto-generated Medical Record Numbers (MRN), full demographic and allergy data

Clinical visit records

Structured documentation covering anamnesis, physical examination (vital signs, general condition, consciousness), nursing & medical diagnosis, treatment (with a searchable medication picker), and discharge/follow-up planning

Auto-generated medical documents

Sick Leave Certificates and Referral Letters, generated as PDF directly from visit data

Dashboard & real-time queue

Daily stats and a live queue view using Supabase Realtime

Reports & analytics

Visit trends, revenue, and diagnosis breakdowns, exportable to Excel/PDF

The Strength

Most of the clinical documentation is selection-based rather than typed: symptoms, history, nursing diagnoses, and interventions are all built as checklists mapped from the case types the practice actually handles, so staff pick rather than type for anything that recurs. Free text is reserved for what's genuinely unique to that patient — vital sign readings, an unlisted complaint, a diagnosis outside the presets.

That's the main speed lever behind the whole system, and it's what keeps documentation — and the patient queue — moving.

Result

No formal usability testing was conducted — validation was continuous through the delivery-feedback loop described above, not a separate testing phase with metrics.

📌

The clearest signal of outcome: the client was satisfied enough with the finished system to request a public demo version specifically to show and promote it to their own contacts — which is why the demo site exists at all. That's not a number, but it's a real, verifiable client action rather than a self-reported score.

Scope Expansion

🔄

Two additions outside the original brief — self-service registration and mobile responsiveness — both driven by how the nurse actually works, not by upfront spec.

Self-service patient registration

Self-service patient registration wasn't originally part of the MVP, which focused on the clinic's internal operations—staff-entered notes, visit documentation, and generated letters. This feature was added midway through the project at the request of the practice's nurses, who wanted to reduce the data entry burden at the front desk: patients filled out their registration details from home, and nurses only had to complete the remaining clinical fields upon arrival.

🔀

This introduced a second user-facing role in the system — patient self-service alongside the internal staff dashboard — without a separate login system or major architectural change, since it writes into the same patient record used everywhere else in the app.

Mobile responsiveness

Mobile responsiveness was another practical addition: since the nurse splits time between hospital shifts and the home practice, the staff dashboard needed to be usable from a phone, not just a desktop. I handled making the interface responsive across breakpoints so patient records, the queue, and reports work on mobile, not just the patient self-registration page.

Learning

This project pushed me past pure UI/UX design into owning a full build end-to-end — discovery, database schema, and shipping a system a real clinic uses daily. The Lovable → Antigravity workflow (validate fast with a disposable v0, then rebuild properly for production) is a pattern I'd repeat: it keeps early decisions cheap to change while still ending in a maintainable, production-grade codebase.

Next Portfolio

Skuma — Simplifying School Management with an Intuitive Dashboard

A personal dashboard design exploring school management, inspired by real work on an LMS platform at Kotakodelabs — built with Radix UI as the design system.

See Full Story →