Project Overview
| Client Industry | Health & Wellness / Technology (Telehealth Platform) |
| Business Type | Seed-funded startup, post-MVP validation, scaling from single-city pilot to multi-market platform |
| Project Duration | 22 weeks |
| AI Service Provided | V1 Product Development |
| Technologies Used | React, Next.js, TypeScript, Node.js, PostgreSQL, Redis, React Native, AWS (ECS, RDS, S3, CloudFront), Stripe Connect, Twilio Video, Auth0 |
The Client Challenge
Following a successful MVP pilot and closed seed round (see our MVP Development case study on this same client), the founders now had funding, a small internal hire, and a mandate to grow but their MVP wasn’t built to support what came next.
The gap between where the product was and where it needed to be:
- The MVP supported one city and independent physical therapists only; the funded roadmap called for multi-city expansion and support for group practices, not just solo providers.
- Insurance billing deliberately excluded from the MVP was now a top investor and customer expectation, and the product had no framework for it.
- The MVP’s booking and scheduling logic was built for a small number of therapists; early stress-testing showed it would not hold up cleanly with hundreds of providers and overlapping multi-location schedules.
- There was no mobile app; investor and customer feedback consistently flagged this as a competitive gap against telehealth alternatives.
- The founders had hired their first product manager and two support staff, but the platform had no admin tooling every operational task (managing disputes, adjusting bookings, verifying therapist credentials) required a developer to intervene directly in the database.
- The MVP’s authentication was basic and needed to support role complexity the original build never anticipated: solo therapists, group practice admins and multi-location staff.
The founders needed the product rebuilt in the areas that mattered for scale without a wasteful full rewrite of the parts that already worked.
Our Solution
Air Brite Labs led the V1 development phase as a targeted evolution of the existing MVP: keeping the validated booking and video consultation experience patients already trusted, while rebuilding the underlying architecture, adding insurance billing, group practice support, a native mobile app and internal operational tooling.
Key capabilities delivered in V1:
- Group practice support — practice admins can manage multiple therapists, shared scheduling and centralized billing under one account, expanding beyond the MVP’s solo-provider-only model.
- Insurance billing integration — patients can submit insurance information at booking, with automated eligibility checks and claims submission handled through a clearinghouse integration.
- Native mobile app — a React Native app covering the full patient booking and consultation experience, addressing the most consistently requested feature gap from MVP users.
- Scalable scheduling engine — rebuilt scheduling logic that correctly handles multi-location therapist availability, timezone differences for multi-city expansion and high-concurrency booking without conflicts.
- Internal admin dashboard — support and operations staff can now manage bookings, resolve disputes, verify therapist credentials and handle refunds without developer involvement.
- Role-based access architecture — rebuilt authentication supporting solo therapists, practice admins, multi-location staff and internal AirBrite/client operations roles with distinct permission sets.
Technical Approach
Architecture Evolution: Rather than a full rewrite, the existing Node.js API and PostgreSQL data model were extended and refactored where the MVP’s assumptions broke down most significantly, the scheduling and availability logic, which was rebuilt to handle multi-location, multi-timezone complexity that the original single-city design never accounted for.
Mobile Development: Built with React Native to maximize code and business-logic reuse with the existing web frontend, sharing API contracts with the web app rather than building a parallel, divergent mobile backend.
Insurance Billing: Integrated with a third-party clearinghouse API for eligibility verification and claims submission, with a dedicated billing service layer that keeps insurance logic decoupled from the core booking flow allowing the platform to support both self-pay and insurance-billed appointments without complicating the booking experience.
Authentication & Access Control: Migrated from the MVP’s basic authentication to Auth0, implementing role-based access control that supports the now-necessary hierarchy of solo providers, group practice admins, multi-location staff and internal operations roles.
Performance & Scale: Redis introduced as a caching layer for therapist availability lookups, which had become a performance bottleneck as provider volume grew; the application layer moved from a single-instance MVP deployment to auto-scaling AWS ECS to handle multi-city traffic patterns.
Admin Tooling: Built a dedicated internal dashboard (separate application, shared backend services) giving support staff booking management, dispute resolution and credential verification workflows eliminating the developer-dependent manual database interventions the MVP required.
Infrastructure: Migrated core infrastructure from the MVP’s Amplify-based setup to AWS ECS with CloudFront for the mobile and web frontend assets, supporting the traffic and geographic distribution needs of multi-city operation.
Implementation Process
- Discovery & Requirement Analysis (Weeks 1–3): Audited the MVP codebase and data model against the funded roadmap, identifying which components needed to scale versus be preserved as-is, and prioritized insurance billing and mobile as the two highest-impact additions based on investor and user feedback.
- Prototype / PoC (Weeks 4–6): Built a proof of concept for the new scheduling engine against simulated multi-location, multi-timezone data to validate the approach before committing to full development.
- Development (Weeks 7–16): Built group practice support, rebuilt the scheduling engine, developed the React Native mobile app and built the internal admin dashboard in parallel workstreams.
- Integration (Weeks 17–18): Integrated the insurance clearinghouse API, migrated authentication to Auth0 and connected Redis caching across the scheduling and availability services.
- Testing (Weeks 19–20): Ran a phased beta with existing MVP therapists and patients migrating to the new platform, plus new group practices in a second target city, validating the insurance billing flow with real claims submissions.
- Deployment (Week 21): Migrated existing MVP users to the V1 platform with zero data loss, launched the mobile app and opened the second city market.
- Optimization (Week 22 and ongoing): Tuned the scheduling engine’s performance based on real multi-city booking volume and refined the admin dashboard based on support team usage patterns.
Key Features Delivered
- Group practice account management with multi-provider, multi-location support
- Insurance eligibility verification and claims submission integration
- Native React Native mobile app for patients
- Rebuilt scheduling engine supporting multi-timezone, high-concurrency booking
- Internal admin dashboard for booking management, disputes and credential verification
- Role-based access control supporting four distinct user role types
- Redis-based performance layer for availability and scheduling queries
Business Results
- The platform successfully expanded from 1 city to 3 cities within the V1 launch window without scheduling conflicts or downtime
- Insurance-billed appointments accounted for approximately 35% of bookings within the first two months post-launch, opening a patient segment the MVP couldn’t serve
- Mobile app adoption reached roughly 60% of active patients within 90 days of launch, addressing the most common pre-launch user complaint
- Support team resolved routine operational tasks (booking changes, disputes) without developer involvement, cutting developer interrupt-driven support requests significantly
- Group practice accounts grew to represent a meaningful share of total provider volume, a segment entirely unavailable in the MVP
- Platform uptime and booking reliability held steady through the multi-city expansion, validating the rebuilt scheduling engine under real concurrent load
Technology Stack
| Layer | Technology |
|---|---|
| Frontend | React, Next.js, TypeScript |
| Mobile | React Native |
| Backend | Node.js |
| Database | PostgreSQL |
| Caching | Redis |
| Authentication | Auth0 |
| Payments & Billing | Stripe Connect, insurance clearinghouse integration |
| Video | Twilio Video |
| Cloud Infrastructure | AWS ECS, RDS, S3, CloudFront |
Why the Solution Worked
The V1 build succeeded because it treated the MVP as a foundation to extend, not a prototype to discard. Patients and therapists already trusted the core booking and video experience from the pilot rebuilding that from scratch would have introduced unnecessary risk and thrown away validated product decisions.
Prioritizing insurance billing and mobile first, based directly on investor and user feedback rather than an internal feature wishlist, meant engineering effort went toward the additions that actually moved the business forward. And rebuilding the scheduling engine before it broke in production based on proactive stress-testing rather than reactive firefighting avoided the kind of scaling failure that derails a lot of funded startups right when growth starts.
Future Scalability
The V1 architecture is built to support the company’s continued growth, including:
- Expanding insurance billing to additional payer networks as the platform enters new markets
- Extending group practice features with more sophisticated staff scheduling and reporting for larger practice clients
- Adding a provider-side mobile app to complement the patient app already shipped
- Scaling infrastructure to additional cities using the same auto-scaling ECS architecture already proven across the first three-market expansion
Because the platform’s scheduling, billing, and access control layers were built as decoupled services rather than tightly coupled MVP-era code, each of these expansions builds on the existing V1 architecture rather than requiring another significant rebuild.
Final Outcome
The platform evolved from a single-city MVP pilot into a multi-city, multi-provider telehealth platform capable of serving both self-pay and insurance patients without discarding the validated product experience that helped the company raise its seed round in the first place. The founders now have a product built to support their next stage of growth, not just their next funding milestone.
