How We Shipped a Telehealth MVP in 9 Weeks — and What Made It Possible
Priya Nair, founder of Ridgeline Health, came to us with a 12-week self-imposed deadline, a clear clinical workflow in mind, and zero tolerance for a product that would need a rewrite six months after launch. She had seen what happens when healthcare teams build fast without a plan — fragile codebases, compliance gaps discovered after go-live, and engineers who hand over work that no one else can maintain.
We shipped her telehealth MVP in 9 weeks. Here is how we got there, what the real constraints were, and what 1,400 patient signups in month one taught us about building healthcare software correctly from the start.
What Ridgeline Health Actually Needed to Launch
The phrase "telehealth app" covers a wide range of products — from a simple video call wrapper to a full clinical management system with EHR integrations, billing, and multi-provider scheduling. Scope clarity at the start of a project like this determines whether you ship in 9 weeks or 9 months.
In Discovery & Scope, we mapped the single care journey Ridgeline needed to prove: a patient finds the platform, completes intake, and completes a first virtual consultation. That is it. No EHR integration. No in-app billing. No multi-clinic routing. Those were right decisions to defer — none of them were needed to validate whether patients would show up and engage.
The core feature set we committed to:
- Patient registration and digital consent capture
- Intake questionnaire with asynchronous review by the clinician
- Secure video consultation (WebRTC-based, with connection quality fallback logic)
- Post-consultation notes and follow-up scheduling
- Role-based access for patients, clinicians, and the administrative team
- Audit logging on every data access and modification — required for compliance
Starting from a clean, well-scoped brief meant the engineering team was never debating what to build mid-sprint.
The Technical Decisions That Made 9 Weeks Possible
Nine weeks is genuinely tight for a healthcare application, where compliance requirements add overhead that a standard SaaS build does not have. The decisions that compressed the timeline were architectural, not cosmetic.
Next.js as the full-stack foundation. React Server Components handled the data-sensitive parts of the application — intake forms, consultation notes, patient records — on the server, which meant patient data never passed through the client browser unnecessarily. That is not just a performance decision; it is a security posture that reduces the attack surface for a HIPAA-adjacent platform. Built-in Route Handlers replaced the need for a separate API server for lighter operations, keeping the codebase unified and the deployment simpler.
PostgreSQL with a structured schema from day one. Healthcare data has relationships that do not fit neatly into a document store. Patient → appointment → consultation → follow-up is a relational chain, and designing it correctly upfront avoids the painful migrations that happen when a document database schema needs to evolve under production load.
WebRTC video with explicit low-bandwidth fallback. We did not bolt a generic video SDK onto the application and call it done. Patients connecting from homes with unstable internet connections should not lose their consultation because of a dropped frame. The video layer degrades gracefully — reducing resolution and frame rate before dropping the call — which matters when the "user" is a patient mid-consultation, not someone watching a YouTube video.
Compliance built into the architecture. Audit logging, automatic session timeouts, role-based data access, encrypted storage at rest — these were implemented in the first sprint, not the last one. When compliance is a final-sprint checklist item, it typically causes a rewrite of the parts of the codebase that were built without it.
Building a healthcare platform and trying to figure out where compliance starts and product ends? Talk to our team about how we scope sensitive builds — we have done this before.
How We Structured 9 Weeks of Work
Projects that ship on time are almost never the ones that planned perfectly. They are the ones that managed uncertainty correctly.
We ran two-week sprints with a working demo delivered at the end of each one. Priya reviewed working software — not wireframes, not a slide deck summarizing progress — at every sprint boundary. That forced three things to stay honest throughout the build: what was actually done, what was not done, and what the real remaining scope looked like.
| Sprint | Deliverable |
|---|---|
| Sprint 1 (Weeks 1–2) | Auth, role-based access, patient registration flow, database schema |
| Sprint 2 (Weeks 3–4) | Intake questionnaire, clinician dashboard, audit log framework |
| Sprint 3 (Weeks 5–6) | Video consultation module, connection quality fallback, post-consultation notes |
| Sprint 4 (Weeks 7–8) | Follow-up scheduling, notification system, admin panel |
| Sprint 5 (Week 9) | Security audit, performance testing, staging deployment, handoff |
The handoff in week 9 was not a ceremonial "here are the files." Priya's internal team received documentation of every architectural decision, the rationale behind each technical choice, and a working knowledge transfer session. The codebase was clean enough that they took it over without requesting a single clarifying rewrite — which was an explicit goal from day one.
What the Numbers Looked Like After Launch
The product went live at the end of week 9. In the first month:
- 1,400 patients completed registration and submitted intake. That is not 1,400 people who clicked a sign-up link — it is 1,400 people who moved through the entire onboarding flow, filled in medical intake forms, and booked a consultation.
- Zero critical outages in the first 30 days. The architecture held under real load without emergency patches.
- Ridgeline's in-house team inherited the codebase without a rewrite. The engineering handoff was the final deliverable, and it worked.
Priya Nair's take: a codebase "clean enough for their in-house team to take over without a rewrite" was not luck — it was the outcome of a team that treated the handoff as a product requirement, not an afterthought.
What Other Healthcare Founders Can Take From This
The Ridgeline Health project was not exceptional because the timeline was short. It was exceptional because every major failure mode in healthcare software development was anticipated and addressed before it could occur.
The founders who come to us after a failed first build almost always point to one of three issues: they tried to build too much in version one, they added compliance as a final-step audit, or they used engineers who were not familiar with the architectural implications of healthcare data. Any one of those three will derail a 9-week timeline. All three together will derail a 12-month one.
The scope discipline in the Ridgeline project — one care journey, fully working, before anything else got added — is the part that is hardest to maintain under founder pressure. The instinct to add features is understandable. The instinct is also expensive.
Frequently Asked Questions
How much does it cost to build a telehealth MVP in India?
The cost varies significantly with scope and compliance requirements. A focused telehealth MVP targeting one care journey — registration, intake, secure video, and post-consultation notes — typically runs in the range of Rs. 12–25 lakh from a quality product studio, depending on the team size and sprint duration. Platforms requiring EHR integrations, multi-provider routing, or insurance billing modules cost considerably more. The cleaner your scope in Discovery, the more predictable the final number.
Do I need HIPAA compliance if I am building a healthcare app in India for Indian patients?
Not directly — HIPAA is a U.S. regulation governing the handling of protected health information for U.S. patients. If your platform serves Indian patients, you are primarily governed by the Digital Personal Data Protection (DPDP) Act, 2023, along with applicable guidelines from the National Digital Health Mission. That said, many of the technical safeguards that satisfy HIPAA — encryption at rest and in transit, audit logging, role-based access control, session timeouts — are also best practices for Indian healthcare data and are worth implementing regardless of jurisdiction.
How do you handle video consultations in areas with poor internet connectivity?
The video layer should degrade gracefully rather than drop entirely. The approach we use on telehealth builds involves WebRTC-based video with adaptive bitrate logic — the connection reduces video quality progressively before disconnecting. For extremely low-bandwidth situations, a fallback to audio-only mode preserves the clinical interaction even when video is not viable. Patients in Tier 2 and Tier 3 cities in India frequently encounter this scenario, so designing for it is not optional.
Can I start with a narrow scope and expand later without a rewrite?
Yes — if the initial architecture was designed with expansion in mind. This is the distinction between a codebase that is minimal and one that is minimal but well-structured. The Ridgeline Health codebase was built for one care journey at launch, but with a database schema and API structure that anticipated additional consultation types, multi-clinic routing, and eventually EHR integration. Expanding a well-structured MVP is an extension. Expanding a poorly structured one is a rewrite with extra steps.
What is a realistic timeline for launching a telehealth MVP?
A focused telehealth MVP targeting one clinical workflow — from intake to consultation — typically takes 8 to 12 weeks with a dedicated product studio. That window assumes clean scope definition before development begins. If discovery happens inside the build timeline, add two to four weeks. If the project requires EHR integration or multi-state compliance logic from day one, the timeline extends to four to six months.
If you are building a healthcare platform and want a direct assessment of whether your current scope and timeline are realistic, book a discovery call with the StartupSphare team. We will tell you exactly what is achievable, what should wait for v2, and what decisions made now will cost you the most to undo later.
Custom Software & SaaS · Success Stories · UI/UX Design · Contact Author: StartupSphare Team Last updated: August 2026