Skip to content

Product engineering

Talk to us Discuss a Project
Talk to us Discuss a Project

Case study · Rural healthtech

VizitDoc

A booking platform for rural patients that began as a full build, was rebuilt as an MVP, and became the origin of how we now approach every early-stage product.

Archived · Operations closed 2021

Engagement
Founding team and engineering
Platforms
Web, telehealth and mobile
Role
Our own product, built in-house
Outcome
Operations closed in 2021 Verify before publishing
A keepsake of VizitDoc, our first product: the platform framed like an album photograph over a heartbeat line at rest, with its tagline, Health At Your Convenience, and the years it served before retiring in 2021.
Industry
HealthTech
Users
Rural patients, doctors, clinics
Focus
Access to urban healthcare
Platforms
Web + mobile
Role
Sister company
Status
Archived

01The business situation

We built the wrong version first, and it taught us everything.

VizitDoc was our own company, set up to connect rural patients with urban healthcare. We built what an inexperienced founder builds: a complete patient portal, full of features we were confident users wanted. Eight months later, the traffic and the conversations told us plainly that most of it was in the way. The rebuild (booking in three to five steps and very little else) is the origin of the MVP Program we now run for clients.

Core challenge

Reach patients with limited connectivity and limited digital familiarity, using a product simple enough to actually complete.

Before

A full-featured portal built on assumption

  • Feature-rich Portal
  • Assumed Requirements
  • Long Booking Flow
  • Urban Assumptions

After

A short booking flow built on observed behaviour

  • Patient
  • Doctor
  • Clinic
  • Telehealth

VizitDoc Platform

02The system at a glance

One goal. Four connected products.

  • Clinic Portal Appointments and practice management
  • Patient Booking Find and book a nearby doctor
  • Doctor Tools Schedule and consultation
  • Telehealth Remote consultation for both sides
Core PlatformAccess-first, built for constrained connectivity
  • Appointment Booking
  • Doctor Discovery
  • SMS Confirmations
  • Telehealth Sessions
  • Clinic Management
  • Search Visibility

03Workflow 01

Three to five steps, and nothing else.

The rebuilt booking flow removed almost everything the first version offered. For a rural user on a weak connection, every additional screen is somewhere to drop out, and the booking is the only thing that matters.

Image placeholder The simplified booking flow: finding a nearby doctor, choosing a slot and confirming, in a few short steps with the SMS confirmation. assets/portfolio/vizitdoc/workflow-booking.png · 16 / 11
  • Utility features removedThe rebuild deliberately stripped functionality that did not serve the booking.
  • SMS, not just screensConfirmations reach patients, doctors and clinic partners by text, which travels where an app does not.
  • Found through searchSearch visibility was treated as a primary channel rather than a marketing afterthought.

04Workflow 02

Then the world changed the requirements.

During Covid-19 the need moved from getting patients to a clinic to reaching a doctor at all. Telehealth portals for both sides followed, and a management portal so clinics could run their own appointments.

  1. 1Patient telehealth

    Image placeholder Patient telehealth screen: the upcoming remote consultation and how to join it. assets/portfolio/vizitdoc/step-patient.png · 1 / 2.04

  2. 2Doctor console

    Image placeholder Doctor application: the day’s consultations, patient details and the consultation controls. assets/portfolio/vizitdoc/step-doctor.png · 1 / 2.04

  3. 3Clinic management

    Image placeholder Clinic management portal: appointments across the practice, doctor availability and scheduling controls. assets/portfolio/vizitdoc/step-clinic.png · 1 / 2.04

05Workflow 03

What we kept was the lesson.

The company ran for more than three years and several products before we closed its operations in 2021. The codebase and IP stayed with us, and so did a way of working that every client project now inherits.

  • Validate before you build wideEach later product validated its essential model before features were added around it.
  • The origin of the MVP ProgramWhat this cost us in time became the method we now bring to client engagements.
  • Structure worth keepingThe engagement set a clear internal standard for how our codebases are organised.
Image placeholder The VizitDoc product family: the patient portal, the doctor and clinic applications and the telehealth portals, shown as one connected ecosystem. assets/portfolio/vizitdoc/product-family.png · 16 / 10
Image placeholder A simple before-and-after: the original feature-heavy portal against the rebuilt short booking flow. assets/portfolio/vizitdoc/mvp-lesson.png · 1 / 2.04

06Engineering behind the product

The system, and how it changed.

This engagement spans a full stack migration and a platform expansion, both driven by what the product learned rather than by technical preference.

  • A stack that was replaced

    The original Django and AngularJS build was migrated wholesale to Laravel and VueJS during the rebuild, when the product direction changed rather than the technology fashion.

  • Search-led acquisition

    Search visibility was engineered into the rebuilt platform as a primary way rural users would find it.

  • SMS integration

    Booking details reach patients, doctors and clinics by text, which is the channel this audience reliably has.

  • Telehealth portals

    Separate patient and doctor applications were added for remote consultation.

  • Clinic management

    A dedicated portal lets clinics manage their own appointments and availability.

  • Queue-backed scheduling

    A queue handles scheduled messaging and booking-related work outside the request cycle.

  • Hybrid and native mobile

    Later products in the family shipped as hybrid apps, with a native iOS build for one doctor-facing product.

07Technical architecture

Under the hood

Two generations of stack: the original full build, and the rebuild that followed the move to an MVP approach.

First build

  • Python 2.x
  • Django
  • AngularJS
  • PostgreSQL
  • AWS

After the rebuild

  • Laravel
  • PHP
  • VueJS
  • Bootstrap

Async & serving

  • Redis
  • Nginx

Cloud

  • DigitalOcean

Mobile

  • Flutter (hybrid)
  • Native iOS

Integrations

  • SMS for booking confirmations

08Delivery journey

How the products were delivered.

  1. First build

    A full portal, built on assumption

  2. User contact

    Eight months of real interaction

  3. Rebuild

    Strip back to the essential booking

  4. Migration

    Move the stack with the direction

  5. Telehealth

    Expand during Covid-19

  6. Product family

    Validate each model before widening

  7. Closure

    Operations closed in 2021

The company operated for a little over three years. Operations were closed in 2021; the IP and codebase remain ours. Dates beyond that are withheld until confirmed. Verify before publishing

09What the engagement produced

What the work produced

  • A booking flow rural patients could actually complete
  • SMS confirmations reaching patients, doctors and clinics
  • Telehealth portals for both patients and doctors
  • A clinic-side appointment management portal
  • A validated approach applied across later products
  • The MVP Program we now run for clients

Related systems

NEMS

Healthcare · FHIR Scheduling · Web

A FHIR-compliant patient scheduling platform for one of the largest non-profit community healthcare providers in the United States.

View case study , NEMS

Bright Edutech

EdTech · Video Learning · Android + Web

A regional-language learning platform for tier-2, tier-3 and rural India, with a custom video pipeline built to keep delivery affordable.

View case study , Bright Edutech

We learned this one the expensive way, so you do not have to.

Prove the essential model first. We will tell you when we think you are building too much.

Discuss your system