Healthcare
Exercise plans for a physiotherapy clinic
A physiotherapist assigns a patient a plan of exercises with videos, sets and frequency. The patient ticks off sessions on their phone and reports pain level. The physio sees who is doing the plan and who is not before the next appointment.
Automatically generated draft
Written by machine against our own engineering playbook. The company is invented; the decisions are the ones we would make on a real build. A reviewed blueprint goes further — nine sections, agreed line by line, and it is what the build is tested against.
Section 01 · What has to work
A physiotherapist assigns exercise plans to patients who log their completion and pain levels on mobile so the physio sees adherence before appointments.
Section 03 · Screens
Every screen, and what it is for.
- ›Plan Builder — physio creates exercise routines, instantly saves to database.
- ›Today View — patient checks off daily sets, instantaneous local tap response.
- ›Adherence Dashboard — physio views patient compliance list, instant load per clinic.
- ›Session Logger — patient records pain slider and notes, instant state sync.
Anything not on this list is not in version one. That is what keeps a fixed price fixed.
Section 04 · The data model
What it stores, and who can read a row.
users
id uuid, role enum(physio, patient), email text, created_at timestamptz
Access · Users can read their own row; physios can read their clinic patients.
plans
id uuid, physio_id uuid, patient_id uuid, title text, status enum(draft, active, completed), created_at timestamptz
Access · Physio and assigned patient can read the plan.
exercises
id uuid, plan_id uuid, title text, video_url text, target_sets int, frequency_per_week int, sort_order int
Access · Anyone who can read the parent plan can read exercises.
sessions
id uuid, plan_id uuid, completed_at timestamptz, pain_level int, notes text
Access · Patient can insert and read; assigned physio can read.
Those access rules belong in the database, not in the screens. Someone who edits the address bar still cannot read a row that is not theirs — and the test that proves it blocks delivery if it fails.
Section 05 · States
draft → active → completed | archived
Most scope arguments three weeks into a build are really arguments about a state nobody named at the start.
Section 06 · Where this breaks
What bites products like this one.
Patients in low-connectivity areas will not be able to tick off completed exercise sessions.
Queue session ticks locally in SQLite and sync when network reconnects.
Video hosting bandwidth spikes when all patients load exercise demonstrations simultaneously.
Host videos on an optimized CDN with adaptive bitrate streaming.
Section 08 · Deliberately left out
What version one does not do.
- ×Real-time chat between physio and patient — high complexity, email and in-person suffice for v1.
- ×Custom video upload by physios — storage and transcoding costs are high; use curated library links for v1.
This is the section that protects the date, and the only place in the document where somebody says no. It is also why clients trust the rest of it.
Still open
What we would ask before quoting.
- How are physiotherapists authenticated and linked to their specific patients upon onboarding?
- What is the maximum acceptable video file size for exercise demonstrations?
Your product, not this one
Get this written for what you are actually building.
Describe it in a sentence and the generator returns the same sections for your own product. Free, no email, nothing saved to a list.
Next step
Find out if your idea fits in 10 working days.
Tell us what you want to build. We reply the same day with a straight yes, no, or here is what we would cut.