How a private GP network in London needed a patient-facing mobile app by a hard deadline — and what it actually took to build one properly under that kind of pressure.
ClearHealth was a network of four private GP practices in London with around 6,000 registered patients. Their booking system worked fine on desktop but was genuinely difficult to use on a phone. Patients were calling the reception desk to book appointments because the mobile web experience was too frustrating to complete.
Their operations manager, Priya Nair, had been trying to get a mobile app built for 18 months. Two vendors had quoted timelines of 6 to 9 months. A third had started the project, billed for three months, and delivered a prototype that didn't match what had been discussed. By the time she contacted us, the CEO had lost patience, and there was a hard deadline: a corporate client contract renewal in six weeks that listed a mobile app as a specific deliverable.
The conversation that made this project work happened in the first 48 hours. We sat with Priya's team and went through every item on their original feature list. For each one we asked: if this feature is not in the app when it goes live in four weeks, does the corporate contract fall through?
Most features didn't pass that test.
Video consultations · Prescription request forms · GP selection preferences · Repeat prescription history · Patient messaging
Patient login · Appointment booking (browse slots, select, confirm) · Upcoming appointments with add-to-calendar · Appointment history · Push notifications for confirmations and 24hr reminders · Admin view for GP staff
Six features. Properly built, properly tested, properly submitted to both app stores. That was the agreement. v2 could have everything else — but only after the contract renewed.
We started with the Node.js API because nothing else could move without it. ClearHealth already had patient records and GP schedules in a PostgreSQL database from their existing booking system. We built an API layer on top — not a rebuild, a well-structured interface the mobile app could call.
Authentication came first. Private healthcare data requires proper session management. We used Firebase Authentication for the patient-facing login — it handles token refresh and session expiry in a way that's both secure and invisible to the user — with all patient data staying in their own PostgreSQL database, never in Firebase.
By end of week 1: a working API, tested in Postman, with authentication, slot availability, appointment retrieval, and booking confirmed.
React Native development started on day 8. We used Expo for faster iteration — no native build configuration overhead — with a planned ejection to bare workflow if any native modules required it. They didn't.
The booking flow had one edge case that needed to be handled correctly: what if a patient opens the slot calendar and another patient books the same slot before they confirm? We used an optimistic lock on slot selection — the slot is soft-reserved for 5 minutes when a patient enters the booking flow, released automatically if they don't complete it. Standard pattern, but it needed to be built correctly or patients would see confirmation errors at the last step.
By end of week 2: login, booking, upcoming appointments, and appointment history — all functional in development.
Push notifications via Firebase Cloud Messaging. Booking confirmations go out immediately. The 24-hour reminder is a scheduled job running every hour — checks for appointments in the next 24-hour window that haven't had a reminder sent, fires the notification. We tested on real physical devices on both iOS and Android. Notification behaviour is different enough between the two platforms that simulator testing alone is not sufficient.
The admin view for GP staff — separate section of the same app, accessible only to admin-role accounts. A day-view list of booked appointments in time order. Staff tap to mark attended or flag a no-show.
Week 3 also included the UI pass. The first two weeks the screens were functional but rough. The design pass brought in ClearHealth's brand colours, proper typography, and touch targets sized correctly for a healthcare app. Healthcare apps that feel cheap lose patient trust immediately.
Five days for testing. Two days buffer for App Store review — Apple's review process is the variable you cannot fully control, and we'd built in time accordingly.
Staff testing with Priya's team on day 22 surfaced two things: the date format in appointment history was displaying in US format (MM/DD/YYYY) instead of UK format, and the GP selection screen didn't make it obvious which GPs were available on the patient's preferred days. Both fixed within a day.
The app was live on both stores at the end of week 4.
The corporate contract renewed. The client's account manager had tested the app the week before the renewal meeting and reported it positively. That was the immediate goal, and it was met.
In the first month after launch, inbound calls to ClearHealth's reception desk dropped 34%. Not eliminated — patients still called for complex requests or anything outside routine booking — but the routine "I need to book a slot next Tuesday" calls that had been taking up reception time dropped significantly. Three of the four practice managers noticed the change without being asked.
The v2 scope is in planning. Video consultations are first — a Twilio-based session that initiates from within the app, with a waiting room the GP opens from their admin view. Prescription request forms are second. Both are targeting delivery in Q3 2025.
The native app question came up at three months post-launch. The PWA-style React Native build had performed well enough that ClearHealth chose to stay with it and revisit a fully native rebuild when the patient base grows and specific hardware features are required.
Every piece of patient data in this app — appointment history, consultation notes, GP preferences — is treated as sensitive. Firebase Authentication stores session tokens only, not patient records. The Node.js API validates permissions on every request, not just at login. Patient data never passes through a third-party service it doesn't need to pass through.
Infomaze is ISO 27001 certified. All engagements involving healthcare or personal data are covered by NDA from the first conversation. Data security isn't something we add at the end of a project — it's part of how we design the system from the first call.
Comparison Guide Progressive Web Apps ✦ Web & PWA Development 8 min read · 2026…
Comparison Guide Progressive Web Apps ✦ Web & PWA Development 8 min read · 2026…
Diagnostic Guide ✦ 23+ Years Building Business Software 8 min read · 2026 Warning Signs…
Diagnostic Guide ✦ .NET · PHP · Classic ASP Migrations 8 min read · 2026…