LIVE · IN PRODUCTION

A clinical patient-diary app

How a compliance-grade clinical MVP went online with real pilot patients in three days — and what the FastTrack cut left out.

Project code: CASE-001
Domain: HEALTHCARE · PATIENT SELF-TRACKING
Investment: from CHF 2,000

A real clinical patient-diary app — multi-tenant auth with per-clinic branding, patient groups with invite links, a customizable intake list, single-use device enrollment, a realtime clinician dashboard, server-generated PDF protocols, an installable PWA, and a privacy-hardened pilot mode signed off for real-patient use under a Swiss revFADP data-processing agreement. Online with real pilot patients in three days — because the FastTrack intake and a ruthless MVP cut decided exactly what to ship first.

At a glance

Idea → live: 3 days
Iterations: 2
Status: Live

Map the landscape

Understand

The clinic was running a patient self-tracking routine on paper — a printed diary patients filled in by hand at home, then staff tallied by hand afterwards. It worked, but it cost clinician hours every week and made it slow to see trends across a whole patient group.

The audience: The clinicians who review the data, and the pilot patients who fill the diary in at home, on their own phones.
The baseline: A paper form, photocopied per patient and tallied by hand — no search, no export, no live view of a group.
The groundwork: An existing intake list and brand assets meant we could skip baseline setup and go straight to the diary itself.

A patient logging an entry on their phone — What replaced the paper sheet — a pilot patient logs a drink (type, volume) or a void (volume, urgency, leakage) in seconds on their own phone, branded per clinic.

Draw the boundaries

Shape

We mapped far more than two weeks could hold, then drew a hard MVP line. The rule was simple: ship the thing that replaces the paper diary first — everything that gold-plates it waits for evidence that the core works.

In the cut: A working patient diary with per-patient IDs, search and CSV export, per-owner branding, patient groups with invite links, a customizable intake list, and a server-generated PDF paper-form.
Held for a second pass: The realtime clinician dashboard and single-use device enrollment were deliberately deferred to a second iteration — valuable, but only worth building once the core diary had proven itself with real patients.
Left for later: The compliance and docs-site authoring — security notes, a data-processing agreement, a user-journey spec — real for a regulated pilot, but paperwork, and never blocking the launch of the app itself.

WIREFRAME

An early wireframe of the patient entry screen — the kind of low-cost sketch we agree on before any code hardens.

Ship something real

Build

The build ran as tight evidence loops, not one long quiet stretch. Because the intake and prioritisation had already drawn a sharp MVP line, the first version was online and in real use within three days — then a second iteration hardened it for pilot patients. Every cycle ended with something real you could click, not a status update.

First, live: The core diary, per-clinic branding, patient groups, the customizable intake list and the PDF protocol — the bulk of the product, online fast because the scope was already decided.
Second iteration: Pilot-grade hardening for real-patient use, single-use device enrollment, the realtime clinician dashboard and PDF audit logging — added once the core had proven itself.
The stack: Deployed natively on Maravilla Cloud with zero pipeline configuration; server-generated PDFs straight from the edge runtime; an installable PWA.

The realtime clinician dashboard — The clinician's realtime read-only dashboard — branded per clinic, updating the moment a patient logs an entry, with intake-vs-output over the day and every entry. It replaced a stack of photocopies.

Hand over the keys

Hand over

Software only becomes valuable when it's used. At hand-over the clinic received a live production app, their typeset project profile, the PDF paper-forms for offline days, and a privacy-hardened pilot mode signed off for real-patient use under a Swiss revFADP data-processing agreement.

A server-generated PDF protocol — A server-generated PDF — the full protocol, branded per clinic, ready to print or hand to the treating physician.

The takeaway

The speed isn't a trick — it's the method. The FastTrack intake surfaces the goal that actually matters, prioritisation draws a ruthless MVP cut, and you ship that first. This app was online with real pilot patients in three days, then a second iteration hardened it for the clinic — nothing built that hadn't earned its place.

That's why "two weeks max, usually faster" is a floor, not a boast.

POST-LAUNCH

Live with real pilot patients — entries logged from day one.

Built on Maravilla Cloud

None of this was bespoke infrastructure. Every capability below is a Maravilla Cloud building block — so the engagement spent its time on the product, not the plumbing.

Authentication: Each clinic signs in to its own tenant; patients never need an account.
Authorization: Per-resource policies isolate every clinic's patients — and turn diary links into single-use, capability-scoped device tokens.
Database: Patients and every diary entry in a document store, queried for the day-by-day summaries.
Storage: Each clinic uploads its own logo for the patient screens and the PDF.
Real-Time Events (REN): The clinician dashboard updates the moment a patient logs an entry — no refresh, no polling.
Event Handlers: A new-entry event fires the clinic's Teams alert automatically.
Push Notifications: Web Push reminders nudge pilot patients to keep their 72-hour diary up to date — delivered to the installable PWA, no SMS and no app store.
Edge Runtime Platform: The whole app — server-generated PDFs and an installable PWA — runs on the edge with zero pipeline configuration.

EXPLORE MARAVILLA CLOUD →

BEGIN YOUR PROJECT → MORE CASE STUDIES