Live demo: https://flowcare-1aan.onrender.com (free tier — first load may take ~50s to spin up) Tech stack: Node.js, Express, Socket.io (real-time), SQLite (better-sqlite3), server-rendered EJS, QR code generation, Chart.js

An end-to-end queue and appointment management platform: live token queues, appointment booking with QR check-in, multi-department patient journeys, wait-time analytics, and a versioned, API-key-secured REST API for outside integrations. Built through MVP → V4 of a real product roadmap, not a mockup.

FlowCare — Full Platform (MVP through V4)

A working, end-to-end build of the platform described in the FlowCare investor proposal — not mockups. Every phase on the deck's roadmap (section 16) is implemented and wired together in one Node.js app: MVP, V1.5, V2, V3, and V4.

Run it, click through it, and it behaves the way the deck describes: tokens, live queues, appointments with QR check-in, multi-department journeys that route themselves, wait-time analytics with trend charts, rule-based bottleneck alerts, a versioned API for outside systems, and a terminology layer that reconfigures the whole app for a different industry in one click.

Running it

Requires Node.js 18+.

npm install
npm run seed   # one-time: creates 2 demo branches, departments, staff (skips if already seeded)
npm start

Open http://localhost:3000. To reset all data: delete flowcare.db and run npm run seed again.

What's implemented, by roadmap phase

MVP — Pilot-ready

• Digital tokens (walk-in or appointment), live queue per doctor/counter, reception dashboard, staff/doctor dashboard, TV display board, ETA calculation, patient status page.
• ETA math: patients ahead × that staff member's average service time — which automatically switches from a configured default to the real historical average once enough patients have been served (deck section 8).

V1.5 — Commercial-ready

• Appointments (/appointments/book): pick a department, staff member, date and 15-minute slot.
• QR check-in (/appointments/confirmation/:id, /checkin/:code): booking generates a real scannable QR code; scanning (or opening the check-in link) converts the appointment into a live queue token on arrival — no app required, per the deck's differentiation point.
• Feedback & reports: post-visit star rating on the patient page, average rating on the admin dashboard, and a one-click CSV export of the day's tokens.

V2 — Enterprise-ready

• Multi-branch: two seeded branches (a full hospital and a smaller clinic), with a branch switcher in the top nav that scopes reception, staff, display, and admin.
• Multi-department journeys: "Start a journey" in Reception chains departments — Registration → Doctor → Lab → Pharmacy → Billing. Completing one step automatically issues the token for the next step, picking whichever staff member in that department has the shortest queue. A /journey/:visitId page shows live progress across all steps, and it's also embedded on the patient's own status page.
• Advanced analytics: a 7-day wait-time trend chart and a per-staff completed-today comparison chart on the admin dashboard, alongside the department breakdown table.

V3 — Platform layer

• Bottleneck intelligence (deck section 10, implemented as real rules, not just mockup text): a department running 2x its own trailing 7-day average wait, an hour where check-ins exceed a department's staffed capacity, abandonment outliers vs. other departments, a slow Registration step, and any staff member with 4+ people waiting — all surfaced as an alerts panel on the admin dashboard.
• Public API (/api-docs): a versioned, API-key-gated /api/v1/* surface (queue snapshot, today's metrics, alerts, remote token creation) so an existing hospital system could integrate without touching the UI. A demo key is generated on seed and printed to the console.

V4 — Multi-vertical SaaS

• Cross-industry configuration (/admin/settings): the queue engine, ETA math, and analytics are identical underneath for every business type — only the terminology changes. Four vertical presets are included (Healthcare, Salon/Spa, Automobile Service, Bank/Government), and switching one re-labels "Patient" → "Customer", "Doctor" → "Stylist", etc. across every page immediately, no restart needed.

How to demo the full flow in one sitting

1. Reception → issue a token for Dr. Kumar. Open Staff in another tab, call/start/complete it. Watch TV Display and Admin update live.
2. Appointments → book a slot, view the QR confirmation, open the check-in link, confirm arrival — you land on the same live patient status page.
3. Reception → "Start a multi-department journey" (Full OPD Visit). Complete each step from Staff and watch the token automatically reappear in the next department with a different staff member, in real time on Admin → Active multi-department journeys and the /journey/:id page.
4. Admin → watch the alerts panel, 7-day trend, and staff performance chart; export the day's tokens as CSV.
5. API (/api-docs) → copy the demo key and hit /api/v1/metrics/today with curl to see the integration surface.
6. Admin → Settings → switch the vertical to "Salon / Spa" and reload Reception — same engine, different language.

Tech stack

• Node.js + Express, server-rendered EJS views (no separate frontend build).
• SQLite via better-sqlite3 — single-file database, zero setup.
• Socket.io for realtime updates across every open tab.
• qrcode for real QR code generation on appointment confirmations.
• Chart.js (bundled locally in public/js/, no CDN dependency) for the trend and staff-performance charts.

What's intentionally still a demo, not production

• No authentication/roles — anyone can reach Reception, Staff, or Admin. Add auth before a real pilot.
• WhatsApp/SMS notifications are simulated by the patient status page link, not sent via a real BSP.
• The bottleneck rules are a reasonable starting rule set, not a tuned model — thresholds should be validated against a pilot's real data.
• Single-tenant: one FlowCare instance per deployment. True multi-tenant SaaS (deck's "cloud-based multi-tenant architecture") would need tenant isolation added to every table and query.
• No compliance/security hardening (encryption at rest, audit logs, consent tracking) — the deck is explicit that this needs a qualified review before production healthcare use, and that hasn't changed.

These are exactly the gaps the deck's own roadmap and risk sections (9, 18, 20, 22) flag as next steps — this build gets you a clickable, working version of everything else so those conversations have something concrete to point at.