All BlueprintsHealth
Clinic appointment booking
Booking for one small clinic: patients find a slot that is genuinely free and take it themselves, the front desk sees the day at a glance, and nobody arrives to be told their time was given to somebody else.
What you’ll build.
A booking site for a clinic. Patients sign up, confirm their email, book a slot that is really free, get a reminder in time to do something about it, and cancel without phoning anybody. Staff open their own screen and see the whole day.
What you’ll learn.
Each sprint is built around one skill. You show you have it in a pull request your team reviews, then explain it in a walkthrough.
Authentication
You can register and sign in a user, keep a request authenticated without asking for the password again, and explain where the credential lives in the browser and why there rather than somewhere else.
Booking an appointment
You can show availability, book a slot, and prove that two simultaneous bookings produce one appointment and one clear refusal.
Roles and permissions
You can give users different roles and have the server refuse what a role may not do — not merely hide the button — and show the refusal working against a request the interface never offered.
Notifications people do not mute
You can notify a user when an event concerns them, show an unread count that survives a refresh, and honour a preference that says stop.
Background jobs
You can hand work to a worker, tell the user it is in progress, and show the result when it lands — and say what happens to that work if the process dies halfway.
Email verification
You can issue a verification link, activate the account when it is followed, and explain what the link contains and why it cannot simply be a user id.
Going live
Somebody who has never met you can open a URL and use the product — and you can say what is different about the copy running there, where its secrets come from, and what you do when a release turns out to be wrong.
The roadmap. 8 sprints, 36 tasks.
Every sprint has a goal and a set of tasks. Open a sprint to see the tasks you will pick up.
Getting in
Somebody can make an account and come back to it.
4 tasks
- A patient can register and land signed in
- Signing back in survives a refresh
- A patient can sign out on a shared machine
- Clinic staff accounts exist, and cannot be self-issued
The diary
A patient can take a free slot, and two patients cannot take the same one.
4 tasks
- The clinic says when it is open
- A patient sees what is genuinely free
- A patient takes a slot and it is theirs
- Two patients, one slot: one wins and one is told
Two sides of the desk
The clinic sees the whole day. A patient sees only their own, because the server says so.
4 tasks
- The front desk sees the day
- A patient sees only their own appointments
- Asking directly for somebody else's appointment is refused
- Staff can book on a patient's behalf
Changing plans
An appointment can be cancelled or moved, and a freed slot goes back on offer.
5 tasks
- A patient can cancel inside the window
- Too late to cancel is a different answer
- A freed slot becomes bookable again
- Rescheduling does not drop the patient in between
- The standby list is told when a slot opens
Reminders people act on
Patients are reminded in time to do something about it, and can turn it off.
5 tasks
- A confirmation when they book
- A reminder that arrives while cancelling is still possible
- A second reminder, closer in
- A preference that says stop is honoured by work already arranged
- Nothing is sent about an appointment that is gone
Work that runs itself
Reminders fire on a schedule without anybody pressing anything, and never twice.
4 tasks
- Reminders go out on a schedule, not on a button
- Running the same reminder twice sends one message
- A failure is visible without a patient reporting it
- Work arranged on Monday uses Wednesday's facts
Opening the doors
A stranger can find it, sign up with an address they actually own, and book.
5 tasks
- Registering sends a verification link
- The link cannot be guessed or reused forever
- Somebody who did not get the email can ask again
- An unverified account cannot book
- The front door explains itself
Put it where people are
The clinic is on the internet at its own address, and the developer is not part of how it stays there.
5 tasks
- A stranger can reach it without you
- Nothing it needs lives only on your laptop
- The email actually arrives
- An address worth giving out
- A bad release can be undone in minutes
Read before you build. The best engineers do.
Senior engineers read the docs before they touch the code. Every Blueprint comes with short documents on the product and its world, the kind a team hands a new hire. Read them well and you ask sharper questions and walk into every review prepared.
What you are building
The product, who it is for, and what finished means.
How a clinic's diary actually works
Domain you will not have: slots, no-shows, and why the cancellation window and the reminder are one decision.
More health Blueprints.
Prescription renewal requests
Repeat prescriptions for one practice: patients ask for more of what they already take, a clinician approves or declines with a reason the patient can read, and every decision stays on a record the product cannot quietly rewrite.
Immunisation record
An immunisation record for families: a parent sees what each child has had and what is due next, a practice sees which of its children are behind, and the card comes out as a file a school will accept.
Therapy intake and consent
Intake for a small therapy practice: new clients fill in one form over as many evenings as they need, consent is recorded against the wording they actually read and the date they read it, and a practitioner sees the clients who are theirs and nobody else's.
Build clinic appointment booking.
Start your free week. Adaeze runs your kickoff, and Lars reviews every pull request.