Revenue Leak Calculator: full PM process on an AI-native build
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.
What this case study is about
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 →The problem I identified
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.
Why I framed it this way
Most product people would have started with the calculator. I started with the forces working against adoption: distrust, inertia, the memory of vendors who sold inflated numbers. Every design decision in the product flows from that analysis, not from what was technically interesting to build. The transparency mechanisms (editable assumptions, conservative defaults, visible benchmarks) are the product. The calculation is the excuse to show up.
Discovery: mapping the job
Before writing a single line of code, I mapped the Job to be Done.
The Job (canonical formulation)
When I suspect my clinic earns less than it could but don't know where the money is leaking or how much it is, I want to see a credible and concrete number of what I'm losing and where, so I can decide whether it's worth doing something about it, without feeling like I'm being sold to.
Forces of Progress mapping
| 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 |
Strategic framing: the data is the product
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."
Three product horizons
Architecture decisions
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 (contact only)Data quality strategy
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.
What I decided not to build (H1)
- WhatsApp automation engine: lives in CRM, not in the app
- AI assistant for the owner: H2 scope
- Paid diagnosis with real extracted data: that's H2
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.
How AI changed the build
| 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.
Reflection
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 (adoption, distrust, inaction, 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.