Overview
Working in general practice, I found myself looking for simple information in places that seemed designed to make it as hard as possible to find. Which room is free? Who is Duty Dr today? Who is supervising the trainees this afternoon? How do we refer to the heart failure clinic? The answers lived across four spreadsheets, external websites and other people's heads.
I measured it in my own practice of 20 to 30 clinicians: the exact same questions could be asked up to nine times a day each, and looking for this information cost me between 10 and 72 minutes a day. None of these frustrations is big on its own. Together they add up to a real contributor to burnout.
What RALPH is
RALPH answers the who, what, when and where of a practice in one place: you and your staff, roles and duties, today and the weeks ahead, rooms and sites. It covers the room rota, rota and leave management, capacity, supervision, cross-cover, announcements and MHRA alerts, and a search across local and national guidance.
My role
Everything, end to end: spotting the problems from my own clinical days, deciding what to build, designing the interface, building the front end, back end and integrations with AI-assisted development, and piloting it with my own colleagues.
Process
1. Start with the most annoying thing
It shouldn't take 30 minutes to find a room and set up a new PC every day. The room rota was the original reason for RALPH, so it got the most care: free rooms and free computers surface at the top, alerts flag anyone without a room, and one click assigns a space.
2. Design rules that come from real NHS desks
- One search for everything. The header search is the one flexible element, because "who / where / how do I" is how people actually ask.
- Never scroll sideways. NHS PCs often have a plain mouse, and a hidden horizontal scroll bar is undiscoverable. Content wraps or stacks instead.
- A consistent frame. The header band lines up with the content below it, the corners stay put, and labels collapse to icons only when they truly have to.
- Every tiny detail gets critical human review. I wanted it to show the amount of care and attention I put into it, and not feel like a basic AI prototype.
3. Leave that knows about capacity
Leave requests show how staffing compares to the practice's usual levels, so the person approving can decide with data. Leave already in the practice's HR software is pulled in through its API; practices without it can use RALPH's own leave management.


4. An assistant that uses the app for you
Ask RALPH works rules first. Everyday questions, like which rooms are free or who is covering results, are answered straight from the practice's own data with no AI model involved. Only when the rules can't answer does it fall back to AI, and that AI works through the same actions a person would: it looks things up, books a tutorial or leave, or proposes a duty change, limited to what that person's role allows. Emergency guidance is always shown word for word, and dates are worked out in code so the model never has to guess.
5. Building it properly
Clinical safety and GDPR thinking came first. RALPH has separate development, staging and production environments, automated end-to-end tests for the details that kept breaking, and a live pilot in the practice where I work. Because RALPH holds no patient data, I balanced login security with ease of use: MFA is required for platform admins and optional for practice staff, so signing in stays quick on a busy day. Each practice's data is kept separate, and I tested that separation across the live practices.
Impact
The partner and rota coordinator have started using it for room rota management, and others are using it daily to look up guidelines. It has been saving me personally up to 40 minutes per clinical day, previously lost to administrative friction or walking around knocking on doors.
“Pretty self explanatory… can't fault it!”GP partner who usually runs the room rota
RALPH is in its first practice pilot, where I train colleagues, gather feedback and keep improving it. Next is understanding how other local practices can be supported, and finding the right balance of customisation.
