How we shipped a healthcare booking SaaS in 5 weeks — Quick Paramarsh teardown

The most common reason healthcare MVPs miss their deadlines: they try to be the next Practo. Quick Paramarsh worked because we said no to that early. Here’s how it shipped.

What we built

Quick Paramarsh is a two-sided appointment booking platform connecting patients with doctors and hospitals across specialties — dentistry, gynecology, neurology, radiology, ICU services. Patients search, filter, and book. Doctors manage slots and confirmations. Hospitals onboard via an admin portal.

The scoping conversation

The first call wasn’t about features. It was about what we were not going to build in version one:

• No insurance integration. Indian insurance APIs are a tar pit. Patients pay direct in v1.
• No teleconsultation.Tempting, but it’s a separate product. Booking first, video later.
• No prescription management. Compliance burden, wrong sequence.
• No patient records / EHR. Critical eventually, irrelevant on day one.
• No mobile app. A great mobile web experience covers 95% of the use case at 30% of the cost. App came later.

What survived: search, doctor profiles, slot management, OTP-based patient login, and a confirmation flow. Five things, shipped well.

The technical decisions

The stack and the why behind each piece:

• Next.js + Tailwind. Default. Server components for SEO on doctor profile pages — important for organic discovery.
• Postgres + Prisma.Healthcare data has relationships. Document DBs are the wrong fit. We’ve never regretted Postgres.
• OTP login via MSG91. Not Firebase. Indian SMS costs are 5x lower on local providers and delivery is more reliable on Indian carriers.
• Razorpay for payments. UPI mandatory. See the other post for the why.
• Hosted on Vercel + Railway. Front and back separated. Vercel handled traffic spikes for free during the launch press cycle.

The week-by-week shape

The schedule we held to, which is roughly the shape of every MVP we ship:

• Week 1: design system, doctor profile page, search results page, database schema. No backend logic yet.
• Week 2: slot management for doctors, admin onboarding for hospitals. First real API endpoints.
• Week 3: patient OTP login, booking flow, confirmation emails + SMS.
• Week 4: Razorpay integration, edge cases on booking (slot conflict, cancellation, refund).
• Week 5: performance pass, soft launch with three hospitals, fix what broke. Public launch day 35.

What we’d do differently

Two things we’d change if we did it again:

• Build the admin panel earlier. We left the hospital admin UI to week 2. Should have been week 1 — it blocked content entry, which blocked our soft launch.
• Hire a writer for doctor bios.We expected doctors to write their own. They didn’t. The first 50 profiles had to be rewritten by the team. Hire someone for this if your platform depends on supplier-supplied content.

The takeaway

A 5-week MVP isn’t a feat of engineering. It’s a feat of saying no — to features, to scope, to the version of your product that lives in your head. The real product is what ships. Everything else is a draft.

If you’re scoping a similar build and want a sanity check, our enquiry form is open. We’ll tell you in 20 minutes which features are essential and which are version-two.