Why this sample
Small clinics take most bookings by phone, and the doctor learns why the patient came only when the patient sits down. A booking app with a short check before the visit is a typical Product-tier job: two apps, one API, real users on day one.
This is a sample build. There is no client, and nothing here is a result from a real clinic.
What it does
- Patients book, move or cancel a visit, in the clinic or by video.
- Before the visit, the app asks a few questions about the symptoms.
- Staff see each summary in a triage inbox, tagged by how soon the patient should be seen.
- The admin calendar shows every doctor’s day and the open slots.
The AI part
The model turns the patient’s answers into a short summary for the doctor and suggests how soon to book. Fixed rules come first: red-flag answers, like chest pain, skip the model and show the emergency number. The app never gives a diagnosis, and a clinician reviews every suggestion.
We would test the triage step with a clinician on a set of written cases before any patient uses it.
Where it stops
No medical records system, no billing to insurers. Both are possible next steps, and both need their own scoping and legal checks.
Timeline
| When | What happened |
|---|---|
| Weeks 1 and 2 | Data model for doctors, slots and visits; booking API; first app build on test phones. |
| Weeks 3 and 4 | Booking flow, reminders, admin day calendar, staff accounts. |
| Weeks 5 and 6 | Symptom check with fixed safety rules, triage inbox, review with a clinician. |
| Week 7 | Store builds, privacy texts, load test, handover and runbook. |