Beta · Pilot validation
Case Study 04 · Healthtech SaaS · 2026

Kira — Emotional support between dental appointments

High-ticket dental clinics lose patients mid-treatment — not because of clinical failure, but because nobody checks in between appointments. Kira is a web app that tracks patient emotional state between visits and alerts clinics before someone disappears.

Type
SaaS · B2B with B2C delivery
Market
High-ticket dental clinics · Chile → LATAM
Stack
Next.js · Supabase · WhatsApp API · Resend
Status
Beta · Entering pilot validation
CLP 50–80k
Monthly subscription per clinic — charged from day 1 in pilot
2 epics
8 user stories · all P0 · complete for MVP build
Score 4.2/5
Viability assessment across technical, business, and marketing dimensions

The problem

Implantology, full-mouth rehabilitation, and adult orthodontics are treatments that take 3+ months and cost several million Chilean pesos. Clinics invest heavily in acquiring these patients — and then lose a significant portion of them mid-treatment, not due to clinical failure, but because the patient got anxious, felt alone in the process, and quietly stopped showing up.

The standard response is reactive: the receptionist calls after a missed appointment. By then, the patient has already decided mentally. There's no system that catches the signal earlier — between appointments, when the anxiety builds and the doubt takes hold.

The real competitor isn't another app. It's the assumption that patients will stay committed to a long, expensive, sometimes uncomfortable treatment without anyone checking in between visits. No Chilean clinic offers this today.

Two-sided value proposition

For the clinic

Real-time visibility into patient emotional state

Individual scores per patient, alerts when someone rates low, and aggregated weekly NPS — so staff can intervene before a patient abandons a treatment that's already partially paid for.

For the patient

Active support before and after each appointment

Guided breathing, relevant information, or calming content — tailored to their specific anxiety trigger (needles, pain, noise, uncertainty). Sent via WhatsApp before the appointment, followed up the next day.

Product design decisions

The patient flow: built around anxiety, not data collection

The patient receives a WhatsApp link before their appointment. They open a web app — no download required — that shows their clinic's branding and asks one question: what worries you most about today's appointment?

01
Select anxiety trigger
02
Receive adaptive content
03
Rate the experience (NPS)
04
Leave feedback or Google review

Five trigger options: needles, pain, noise, uncertainty, nothing in particular. Each routes to different content — a breathing exercise for needle anxiety, a step-by-step procedure explanation for uncertainty, a curated playlist for noise sensitivity. Selecting a trigger advances automatically — no extra "continue" button. Every friction point removed matters when the user is already anxious.

The clinic dashboard: intervention before abandonment

The staff dashboard shows what happened today without requiring case-by-case review: sessions completed, trigger distribution, aggregated NPS, and a prioritized list of low-rating responses flagged for follow-up. The insight the clinic cares about — who needs a call before they disappear — surfaces automatically.

White-label experience by design

The patient sees their clinic's logo, colors, and team — not Kira's brand. This was a deliberate product decision: in high-ticket dental, the relationship is with the clinic. Kira is the infrastructure, invisible to the patient. The clinic configuration screen lets staff upload their logo, set brand colors, and add their team members — and shows a live preview of exactly how the patient will see it.

The key scope decision: no callbacks, only feedback

An early version of the low-rating flow asked for the patient's name and phone number so the clinic could call them back. We removed this in a design iteration. Asking for contact details at the moment of lowest trust — right after a patient indicated they had a bad experience — is exactly the wrong ask. The current flow accepts a free-text message only. If the clinic wants to follow up, they can reach out through existing channels. The feedback is what matters first.

Business model

Monthly SaaS subscription per clinic: CLP 50,000–80,000/month, charged from day 1 of the pilot. The goal in this phase is not revenue — it's confirming real willingness to pay. A clinic that pays, even a small amount, is a fundamentally different signal than one that agrees to try something free.

Distribution is direct: the first pilot clinics come from an existing RevOps client relationship with high-ticket dental clinics. This eliminates the cold outreach problem that kills most B2B MVPs before they start.

Technical architecture

LayerTechnologyWhy
Frontend + BackendNext.js (App Router)Server Components for clinic data · Client Components for the interactive patient stepper
Database + AuthSupabaseRLS from day one — patient data never crosses clinic boundaries
MessagingWhatsApp Business API (Twilio)Dominant channel in Chile · required for pre-appointment link delivery
Email notificationsResendClinic alerts on low NPS responses · best-effort (failure doesn't block patient flow)
StorageSupabase StorageClinic logos and professional photos · write policy scoped to own clinic only

One critical data design decision: the patient's emotional state answer (anxious, nervous, calm) is used only to personalize copy and transitions in real time — it's never persisted to the database. What's stored is the trigger selected, the content shown, and the NPS rating. This keeps the data model defensible under Chile's data protection law (Ley 19.628) without requiring explicit health data handling protocols.

Risks and mitigations

WhatsApp Business API approval delay — verification can take 1–3 weeks and blocks the core delivery mechanism
Medium
Medium
Zero validated conversations with real clinics — the viability assessment assumes the pain is real; it needs to be confirmed with actual clinic owners before scale
High
High
Patient adoption — if patients don't open the link, the clinic dashboard has no data, and the value proposition collapses
Medium
Medium
Single WhatsApp API provider dependency — no fallback defined if Twilio approval is revoked or service fails
Low
Medium

Columns: Probability · Impact

What's validated so far

What the pilot will validate

Why this product, and what it signals

Kira sits at the intersection I've worked in for 15 years: healthcare service design + patient experience + digital product. The problem is real — I've seen it from the inside in clinical environments. The solution is a product, not a consulting engagement, which means it can scale without my time.

The design decisions in Kira reflect the same thinking as the HSJD project: the bottleneck is almost never where people assume it is. Clinics think they lose patients because of price or clinical quality. The actual driver is the emotional experience in the gaps between appointments — where nobody is looking.

Building Kira also demonstrates something the other case studies don't: I can take a product from zero-to-documented without a team. Full PRD, user stories, design system, technical architecture, and business model — before the first line of code. That's the product discipline that scales.

← Revenue Leak Calculator ← Back to all work