Skip to content
Code by Pawpu

2026

DocIndy

Live telehealth web product at docindy.ivisitdoc.com — care discovery, patient start flows, and checkout.

Case study · Software Engineer · professional product delivery

Written by Al Beltran (Al Andrew Paul Beltran), Software Engineering Lead.

Desktop, tablet, and iPhone 16

01 · The problem

A multi-specialty telehealth brand has to move people from care discovery into intake and checkout without fragmenting the journey across weight loss, sexual health, and adjacent specialties.

DocIndy is a public telehealth product at docindy.ivisitdoc.com. The site presents weight-loss and related care journeys, a BMI starting point, partner wellness apps, and login/get-started paths into intake. I contributed professional product delivery on this patient-facing web product.

02 · My role

Software Engineer · professional product delivery

03 · The result

Contributed to the production Vite web product: public care surfaces, patient start flows, and the live frontend that ships at docindy.ivisitdoc.com. Clinical claims on the marketing site are the product's — not personal performance metrics.

04 · Architecture

  1. 01

    Public Vite SPA at docindy.ivisitdoc.com

  2. 02

    Care-category marketing and shop surfaces

  3. 03

    Patient login and get-started paths into intake and checkout

  4. 04

    Partner wellness app surfaces on the same public site

The story

The constraints
A multi-specialty care brand still needs one obvious next step. Clinical claims stay on the product — not in this case study.
The hard part
Keeping weight-loss, adjacent specialties, and intake on one public start path without fragmenting the journey.
The trade-off
A single Vite SPA is faster to ship than a suite of microsites. It also concentrates every specialty's copy in one release.
What broke
Nothing I can publish as a client incident. The hard part was editorial, not a named outage.
What changed
The live site is the record: care journeys, shop, BMI start, partner apps.
What I would do differently
I would keep the same hard line between UI delivery and clinical proof, and I would instrument the get-started path before adding another specialty.

Diagram

Sanitized architecture. Hover is optional — tap or focus a box.

Patient

Purpose
Arrives from search or a partner app.
Trade-off
One entry, many specialties.
Scale
CDN and static assets do the easy work.

Implementation

  • Homepage care journeys spanning weight loss and related specialties
  • Shop and get-started paths into patient intake
  • BMI starting-point tool on the public site
  • Partner wellness apps: Vita247, HealthScan247, and MedTracker

Challenges & outcomes

Challenges

  • Keeping a multi-specialty care story coherent on one public start path
  • Shipping patient-facing flows without treating marketing copy as clinical proof

Outcomes

  • Live production site at https://docindy.ivisitdoc.com/
  • Shipped as professional product delivery, separate from Momentra Labs personal products

Lessons

  • Healthcare product sites need a hard line between UI delivery and clinical claims
  • Multi-specialty journeys still need one obvious next step for patients