Healthcare clinics lose revenue to invisible process failures — but can't quantify it. I applied full product discipline: JTBD, PRD, architecture spec, data strategy, and shipped a live product in 4 days using AI as the development lever.
This isn't a case study about building a tool. It's a case study about applying full product management discipline to a product I built myself, using AI as the development lever. The decisions were real. The product is live.
View live product →Dental clinic owners in Latin America operate with chronic revenue leakage — patients who don't show up, budgets that don't get accepted, treatments that start but never finish, and a dormant patient base that was never re-engaged. Most owners suspect something is wrong. None of them can quantify it.
The standard approach from growth agencies: cold outreach with vague promises about "recovering patients." The result: distrust. Clinic owners have been burned by vendors selling unsubstantiated claims.
The competitor of a revenue leak calculator isn't another calculator. It's the owner's inaction and inherited distrust from bad agency experiences. Which means the feature that matters most isn't calculation accuracy — it's credibility of the number.
Before writing a single line of code, I mapped the Job to be Done.
| Force | What it looks like | Design response |
|---|---|---|
| Push (toward product) | Pain of unresolved suspicion · bad month · gaps in schedule | Lead with the number, not the pitch |
| Pull (the promise) | Concrete number in 10 minutes · curiosity | Fast, frictionless flow |
| Friction (to overcome) | Distrust: "Is this inflated to sell me?" · Effort: "I don't have these figures" | Transparent benchmarks · editable assumptions · conservative defaults |
| Anchor (status quo) | "I've operated like this for years" · "I'll deal with it when critical" | Quantify the invisible cost of inaction |
The calculator has two simultaneous functions: a lead magnet that replaces cold outreach with value delivery, and a data capture instrument that feeds a proprietary benchmark database with every use.
The strategic principle: at 20–30 reports, I can say something no competitor can — "Based on real data from the Chilean dental market — which only we have — your leak is exactly this."
The first version was a single HTML file with all logic in JavaScript — meaning anyone could read the formula in DevTools. That's the core differentiation, exposed in plain text.
Non-negotiable constraint: calculation logic cannot be visible on the client side.
Decision: move all calculation to a backend. Frontend collects inputs and displays results. Never sees the formula.
┌─────────────────┐ inputs (9 data points) ┌──────────────────────┐
│ FRONTEND │ ─────────────────────────▶ │ BACKEND │
│ (owner sees) │ │ (no one sees) │
│ │ ◀───────────────────────── │ · 4-leak logic │
│ · Collects data │ results only │ · ROI ramp │
│ · Displays │ │ · The method │
└─────────────────┘ └──────┬───────────────┘
│
saves everything ◀──────────┤──────▶ contact only
│ │
┌───────────▼──────────┐ ┌────────────▼───────┐
│ Benchmark database │ │ CRM │
│ (the data moat) │ │ name, email only │
└──────────────────────┘ └────────────────────┘
Boundary 1: logic never crosses to frontend
Boundary 2: detailed analysis never goes to CRM — only contact
The calculator is public. Curious visitors will type fake data. Contaminated benchmarks are a liability, not an asset. My principle: mark at entry, filter at analysis.
Don't reject data on input — that adds friction and penalizes real owners. Instead, tag each calculation with quality signals: Did they leave contact? Are values in plausible ranges? Did they complete suspiciously fast? Clean at analysis time, not entry time. With volume, noise becomes a statistical problem with known solutions.
Saying no to these in H1 was product discipline, not a resource constraint. Building H2 before H1 captures clean data is the classic mistake of jumping horizons.
| PM Stage | How AI was used |
|---|---|
| Discovery | Synthesizing JTBD framework, pressure-testing the Forces of Progress map |
| Strategy | Structuring the three-horizon roadmap, defining H1 scope boundaries |
| Architecture | Designing the frontend/backend separation spec |
| PRD | Writing a full PRD with data quality strategy before build started |
| Build | Claude Code for frontend and backend implementation |
| Design | Design brief and visual system for Sprint 2 redesign |
AI was the development lever, not the product thinking. The JTBD, the strategic framing, the architecture decisions, the data quality design — those were product judgment calls. Claude executed them.
This project taught me something about the difference between building a tool and building a product. A tool solves a functional problem. A product manages forces — of adoption, distrust, inaction, and motivation — in addition to the functional problem.
The calculator's most important design decision wasn't technical. It was the commitment to transparency: showing benchmarks, making assumptions editable, defaulting to conservative estimates. That's the anti-distrust mechanism. It's also what makes it hard to copy.
The data quality strategy was the most counterintuitive decision: don't reject bad data at entry, mark it and filter at analysis. That feels wrong until you understand the goal isn't a clean form — it's a usable benchmark database. Different problems, different solutions.
What I'd do differently: instrument the funnel from day one. The first version had zero visibility into where users dropped off. That's the most expensive technical debt in a product built to learn.