Proof of Concept for Employer-Site Dental Care Pods
Let's Connect
Overview
What we built
A regional dental group needed to know whether mobile care pods on employer campuses could work before betting on a national rollout. We built a ten-week proof of concept that answered the question with live utilisation data.
In plain terms: the group wanted to park compact mobile dental clinics at corporate campuses and rotate them between sites, but had no evidence the model would hold up. Employees had no way to book a visit around their working day, employers had no view of when a pod would be on site, and nobody was measuring whether chairs were actually being filled. Committing capital to a national rollout on that basis felt like a guess, and the leadership team needed a defensible answer within a quarter.
We built the smallest system that could settle the argument. In ten weeks the pilot had an employee booking app tied to each campus's visit calendar, an employer portal for scheduling pod days and viewing anonymised utilisation, and an operations console for the mobile teams. Every screen fed the numbers that mattered. By the sixth week of the pilot, chair utilisation across the 12 pilot campuses averaged 82%, 68% of first-visit employees rebooked for the next rotation, and the group reached its go/no-go rollout decision in 10 weeks instead of after a projected 9-month full platform build.
The Problem
Rollout bet with no evidence
The pod concept looked strong on paper: compact mobile clinics rotating across corporate campuses, bringing dental care to where employees already spend their day. But the operational questions were unanswered. Would employees actually book around their working day? Would they turn up? Would they come back when the pod next rotated through? The group had no booking channel, no employer-facing scheduling and no utilisation data with which to answer any of it.
The default path was a full platform build, and internal projections put that at 9 months, which meant committing serious capital before a single operational assumption had been tested. The leadership team was unwilling to make a national rollout bet that way, but it also could not wait: it needed a defensible answer within a quarter.
The gap was not just technical. Employers hosting a pod needed to schedule pod days and see whether the service was being used, without exposing individual employees' health visits. Mobile teams needed to run a day's rotation without paperwork. None of that existed, so every conversation about the rollout ran on opinion rather than evidence.
No booking channel
Employees had no way to book a pod visit around their working day, so demand for the service was invisible and untestable.
No employer visibility
Host companies could not schedule pod days or see anonymised utilisation, so there was no employer-side case for giving the pods campus space.
No utilisation data
Nobody was measuring chair utilisation, no-shows or rebooking demand, which were exactly the numbers the national rollout decision would turn on.
All-or-nothing build
The only plan on the table was a projected 9-month full platform build, an all-in commitment made before any operational evidence existed.
What it was costing them
Every month of indecision kept capital parked against a rollout nobody could defend, while the pods' operational questions stayed open. A full platform build would have consumed a projected 9 months and serious budget before the first real utilisation number arrived, and if the model failed, the group would have discovered it only after the most expensive possible experiment.
The Solution
Instrumented ten-week pilot build
We designed the proof of concept around the decision, not the product. The brief was deliberately thin slices: build just enough of each surface to run real pod days on real campuses, and instrument every screen so utilisation, no-shows and rebooking demand were captured from the first visit onwards. Feature-completeness was explicitly out of scope.
Three surfaces went live inside the ten-week window. Employees got a booking app tied to each campus's visit calendar, so appointments fitted around the working day rather than fighting it. Employers got a portal to schedule pod days and view anonymised utilisation, keeping individual visits private while showing the service was earning its place on campus. The mobile teams got an operations console to run each day's rotation.
Calendar-aware reminders were built in from the start, nudging employees ahead of their slot with an awareness of their working day. That single mechanism carried much of the pilot's operational weight, holding the no-show rate at 6% against the group's 17% in-clinic average, and proving that the booking experience, not just the clinical offer, would decide whether pods worked.
Key decisions
Build for the decision
Every screen was instrumented to answer the rollout question, utilisation, no-shows and rebooking demand, rather than to look finished or feature-complete.
Thin slices over full platform
We shipped the minimum viable version of each surface, replacing a projected 9-month full platform build with a ten-week instrumented pilot.
Book around the working day
The employee app tied bookings to each campus's visit calendar, so a dental visit slotted into the workday instead of competing with it.
Anonymised employer visibility
The employer portal showed pod-day utilisation without exposing which employees attended, giving host companies evidence while protecting individual health privacy.
Reminders as infrastructure
Calendar-aware reminders were treated as core plumbing rather than a nice-to-have, and they held no-shows at 6% against a 17% in-clinic average.
Measurable Impact
What changed after launch
The pilot delivered the evidence the capital decision needed. Chair utilisation across the 12 pilot campuses averaged 82% by the sixth week, 68% of employees who attended a first visit rebooked for the pod's next campus rotation, and the no-show rate held at 6% with calendar-aware reminders, against the group's 17% in-clinic average.
Most importantly, the go/no-go rollout decision was reached in 10 weeks, replacing a projected 9-month full platform build with an answer grounded in live operational data. The group now debates how to scale the pods rather than whether they work, and the pilot's instrumented surfaces give the rollout a working head start.
Rollout evidence
Opinion-led debate with no operational data
Live utilisation, no-show and rebooking numbers from 12 campuses
Employee booking
No way to book around the working day
Booking app tied to each campus's visit calendar
No-show rate
17% average across the group's in-clinic operations
Held at 6% with calendar-aware reminders
Decision timeline
A projected 9-month full platform build
Go/no-go rollout decision reached in 10 weeks
Headline results
Chair utilisation across the 12 pilot campuses averaged 82% by the sixth week of the pilot
Go/no-go rollout decision reached in 10 weeks, replacing a projected 9-month full platform build
68% of employees who attended a first visit rebooked for the pod's next campus rotation
No-show rate held at 6% with calendar-aware reminders, against the group's 17% in-clinic average
Tech & Tools Used
What powered the build
Every tool below earned its place in this engagement. Here is the part each one played.
Next.js
Powered the employee booking app and employer portal, letting us ship instrumented, campus-aware screens quickly and iterate on them between pod rotations without disruptive releases.
Node.js
Ran the backend services behind bookings, campus visit calendars and the operations console, coordinating the rotation schedule that every surface of the pilot depended on.
PostgreSQL
Stored bookings, campus rotations and visit outcomes in one relational source of truth, so utilisation, no-show and rebooking figures could be trusted at decision time.
Prisma
Gave the pilot a typed data-access layer over PostgreSQL, keeping the schema honest while the thin-slice scope shifted from week to week.
Twilio SMS
Delivered the calendar-aware SMS reminders that nudged employees ahead of their slot, the mechanism that kept the pilot's no-show rate far below the in-clinic norm.
SendGrid
Handled transactional email: booking confirmations for employees and pod-day notifications for employer contacts, keeping every party aligned on when a pod would be on site.
Auth0
Managed sign-in across three very different audiences, employees, employer administrators and mobile operations teams, without the pilot having to build its own identity stack.
Metabase
Turned the pilot's instrumentation into the utilisation, no-show and rebooking dashboards that the leadership team read weekly and ultimately based the go/no-go decision on.
Vercel
Hosted the booking app and employer portal with preview deployments for every change, so each thin slice went from build to live campus use within days.
Ready to Build your Dental Healthcare Business with Proof of Concept Builds
Ask Byte
Ask Byte
Typically replies instantly
just Now
Hi! I'm OrganByte's assistant. How can I help you today?
AI-generated content may be incorrect
