Dental Specialist AI

Matrix Dental Case Study + AI Platform Strategy + Production Plan

5-specialist research synthesis. Maps every customer + staff touchpoint, designs AI-augmented service, picks the platform, gives the production plan.

Compiled by Niki, 2026-05-07.

Executive Summary

We picked Matrix Dental Specialists (Century City, Cape Town) as the reference SA dental specialist practice. 5 specialists in parallel: web research, patient journey mapping, customer-facing AI touchpoints, staff-facing AI augmentation, AI platform recommendation.

The headline findings:

1. Matrix Dental is multi-disciplinary — 3 registered specialists (Periodontology + Prosthodontics + Endodontics), 1 general dentist (Invisalign provider), 1 hygienist. Services span implants, ortho, endo, prosth, perio, paeds. Communication channels are phone + WhatsApp (072 569 4476) + web form. No public online booking, no FAQ, broken information architecture.

2. The patient journey has 27 customer-facing touchpoints across 15 stages (Discovery → Long-term Maintenance) per specialty. The biggest revenue leaks are at Stage 1 (booking — 40 % of after-hours enquiries lost), Stage 5 (treatment plan + quote — 35-50 % drop-off), and Stage 14 (recall — 50 %+ industry-wide failure).

3. Staff-side automation can recover ~70-90 hours/week at a 4-doctor practice — equivalent to 1.5-2 FTE redirected from clicking screens to caring for patients.

4. AI platform verdict: Anthropic Claude + n8n + per-patient markdown vault — same architecture as YBA Edge Foothold, applied vertically. OpenClaw stays a parallel build-track, not the dental vehicle. Pick A (Foothold pattern) over Pick B (OpenClaw retrofit) because OpenClaw isn’t a dental runtime — it’s a code-writing crew, and trying to make it one means rebuilding Foothold inside someone else’s opinions.

5. Cost ceiling per practice tenant: ~R1,500/mo all-in (Anthropic + Whisper + infra). Fits cleanly inside R8-15k/mo practice subscription pricing at 85 %+ gross margin.

6. First dental tenant live: 30-45 engineer-days from Captain’s go.

Part 1 — The Practice (Matrix Dental Specialists)

1.1 Site Overview

URL: matrixdental.co.za · Century City, Cape Town · Multi-disciplinary specialist practice. Mon-Fri 08:00-17:00, Sat 08:00-13:00.

1.2 Specialists on Staff

1.3 Service Catalogue

• Periodontology + Oral Medicine — gum disease, regenerative perio surgery, gum graft, gummy smile correction, oral cancer screening, lichen planus, ulceration, lesions
• Implants — single-tooth, multi-tooth, All-on-4 / All-on-6 / All-on-X, overdentures, bone grafts, sinus lifts, immediate implant rehabilitation, Socket Shield
• Prosthodontics — crowns, veneers (ceramic + composite), digital design + fabrication
• Endodontics — root canal therapy with CBCT-assisted diagnosis, post-RCT restorations
• Orthodontics — traditional braces, aesthetic braces, Invisalign
• Paediatric — fillings, cleanings, extractions, preventative + interceptive ortho, Twin Block, palatal expanders, conscious sedation
• Hygiene + general — scale + polish, non-surgical perio, whitening

1.4 Communication Channels (visible)

• Phone reception: 021 110 5764
• WhatsApp + emergency: 072 569 4476
• Web contact form
• Web referral form (with letter upload)
• Specialist email addresses: bmjperio@matrixdental.co.za, rhprostho@matrixdental.co.za
• Social: Facebook, Instagram, YouTube, TikTok
• No public-facing online self-service booking calendar
• No general practice email

1.5 Visible Gaps + AI Opportunities (14 found)

1. FAQ page is broken — same question repeated 5×. Easiest immediate win.
2. No online booking — only static forms. AI booking agent on WhatsApp could triage intent.
3. Dr Mayet has no bio page despite being a referral target — inconsistent.
4. Prof Vorster missing from referral form’s specialist dropdown — endo referrals can’t be routed digitally.
5. No medical-aid scheme list, no pre-auth workflow, no quote/estimate generator.
6. No referral-status tracking for the referring dentist.
7. No structured pre-op / post-op patient instructions beyond a generic theatre PDF.
8. No multi-language support declared in a multilingual market.
9. No accessibility / parking statement.
10. Endodontic services page is thin — no mention of retreatment, apicectomy, microsurgery.
11. Blog has no dates, no categories, no author tags — SEO + trust loss.
12. No referral-letter auto-parser.
13. Specialist mailboxes exposed in raw HTML but not advertised.
14. No dedicated emergency triage page.

These 14 gaps are exactly where AI-augmented service shines.

Part 2 — The Patient Journey

2.1 The 15-Stage Journey Template

Every dental specialist patient flows through some subset of these 15 stages:

Discovery → Booking → Pre-consult prep → First consultation → Diagnostic phase → Treatment plan + quote → Medical aid pre-auth → Treatment scheduling → Pre-treatment prep → Treatment session(s) → Immediate post-op (24-48h) → Healing/interim → Follow-up appointments → Treatment completion → Long-term maintenance + recall

2.2 Six Specialty Workflows — Highest-Leverage Touchpoints

For each specialty, these are the stages where AI delivers the biggest patient impact:

Implants / Oral Surgery

• Stage 1 (Booking): AI WhatsApp receptionist — captures medical history short-form, books real-time, sends calendar invite. Recovers the 40 % of after-hours enquiries currently lost.
• Stage 5 (Plan + quote): Plain-English quote with side-by-side comparison (single implant vs bridge vs denture), monthly payment options, scheme cover, gap explicit. Voice note from specialist explaining recommendation. Cuts 35-50 % drop-off.
• Stage 10 (Post-op 24-48h): Scheduled check-ins at 4h, 12h, 24h, 48h. “How’s the pain on 1-10?” Escalates on red-flag answer. Reduces ER visits + complaints.
• Stage 11 (Healing 3-6 months): Monthly value-add WhatsApp during the silent osseointegration period. Owns the silence.
• Stage 14 (Maintenance): Lifetime recall engine with annual implant-specific review, photo comparison year-on-year, warranty status.

Orthodontics

• Stage 9 (Treatment 18-24 months): AI adherence engine — aligner wear-time tracking, photo check-ins, missed-appointment recovery within 48 hours.
• Stage 14 (Retainers FOR LIFE): Replacement reminders every 12 months; scan-and-mail new retainer service; lifetime relapse-protection plan. Industry has 80 % retention failure within 5 years — this is enormous.

Endodontics

• Stage 0/1 (Emergency triage): 24/7 AI triage on WhatsApp — pain level, swelling, fever — routes to on-call or first-available. Same-day or next-morning emergency slot held in diary.
• Stage 12 (Warm handover): Full notes back to GP dentist with healing X-ray, closing the referral loop and locking in referrer loyalty.

Prosthodontics

• Stage 11 (Lab turnaround 2-3 weeks): Day-by-day expectation calendar; weekly lab progress photos.
• Stage 6 (Pre-auth): AI cross-checks codes against the scheme rules engine before submission — pre-empts rejection.

Periodontics

• Stage 11 (Healing 6-8 weeks): Daily 30-second WhatsApp coach — technique videos, mouthwash reminders.
• Stage 14 (Perio maintenance subscription): Prepaid annual plan, auto-booked, hygienist + perio combo, gum-health score tracked over time. Industry has 60 % non-compliance at 18 months.

Paediatric

• Stage 2 (Pre-consult prep pack for parents): 3-min animated video for the child to watch, age-appropriate vocabulary script (“sleepy juice” not “injection”).
• Stage 14 (Family dental dashboard): Every family member’s recall, history, photos, payments in one WhatsApp chat — locks in family churn risk when child becomes teen.

2.3 Cross-Cutting Highest-Leverage Stages

The stages that recur as highest-impact AI intervention points across all six specialties:

Part 3 — Customer-Facing AI Touchpoints

3.1 The Design Rule

Helpful + caring + pre-emptive — never overbearing. If a message could be cut without the patient missing it, it gets cut. Silence is a feature.

3.2 The 27 Touchpoints (mapped to stages)

Pre-Consultation (Stage 1-2)

1. Booking confirmation — instant after booking, single WhatsApp message, calendar invite
2. Reminder 7 days before — single touch, three options (yes / reschedule / question), no chase
3. Reminder 24 hours before — what to bring, fasting if applicable, “running late is okay” line
4. Pre-consultation prep form — mobile-friendly, only sent if medical history >6 months old
5. Day-of arrival info — parking, building, check-in, estimated time, “see you just now” (SA voice)

During Visit (Stage 3 in-practice)

6. Arrival check-in via QR — confirms presence + tea/water station orientation
7. Wait-time updates — only fires if delayed, honest, offers coffee-shop option

Treatment Plan + Quote (Stage 5)

8. Treatment plan delivery — plain-English summary first, clinical PDF second, “any questions, just ask me here — clinical questions go to Dr X”
9. Quote breakdown — total, scheme cover, patient portion, payment options 1/2/3, “no rush — take your time”
10. Pre-auth status updates — only when there’s news, no filler “still waiting” robot
11. Decision support — patient asks “should I do this?” → AI explains options, never practises medicine, offers free 10-min specialist call

Pre-Treatment Day (Stage 8)

12. Medication reminders — only for prescribed timing-sensitive meds (antibiotics, fasting), never for “as-needed” painkillers
13. What to expect on the day — practical, specific, “bring earphones if you’d like to listen to music”
14. Anxiety-reduction — only for flagged anxious patients; offers hand-raise pause signal, support-person space, breakfast advice

Post-Treatment Immediate (Stage 10, 24-48h)

15. The “are you OK?” check — specific question (“how’s the numbness wearing off?”) at T+4h, three honest reply options
16. Pain management — clear thresholds, what to do, what to escalate
17. Red-flag detection — symptom keywords trigger immediate escalation; AI never diagnoses, always triages
18. Diet + activity — three things only, ranked, with the “why” (e.g. dry-socket explanation)

Healing (Stage 11)

19. Clinically-appropriate check-ins — Day 1 / 3 / 7 / 14, then silence promised: “I’ll be quiet now and you’ll hear from me again at your 6-week review” — the most important line in the system
20. Healing photos (optional) — “snap a photo of the site if you’d like, skip if you’d rather not”
21. Symptom triage — patient asks “is this normal?” → AI handles routine, sets clear “when to worry” thresholds, offers to file note for follow-up

Follow-up + Recall (Stage 12, 14)

22. Follow-up scheduling — three slot options including Saturday for working patients
23. Recall reminders — “book me / remind in a month / not right now thanks” — Reply 3 = AI silent for 12 months
24. Personalised recall — “Mr Smith, your implant is approaching 5-year mark. Some patients ask about whitening at this stage — happy to add or skip entirely”

Ongoing Relationship

25. Birthday — once a year max, no promo, signed by team
26. Practice news — only when patient-relevant (new specialist they’ll see, new tech that affects their procedure)
27. Educational content — pull, not push — only when asked or directly justified by treatment

3.3 System-Wide Rules

• Silence is the default. Empty checkpoints deleted, not filled with filler.
• Quiet hours: 19:00 - 08:00 SAST (clinical red-flags excepted)
• Frequency cap: max 1 outbound AI message per 24 hours (clinical messages override)
• Escalation SLAs: Clinical red-flag <30 min · Clinical question <4 working hours · Admin/billing <4 working hours · Routine query AI handles
• POPIA + clinical privacy: WhatsApp Business API only (encrypted, opt-in). SMS gets “please check WhatsApp / email”. Patient can request “AI off, humans only” at any time — single command, instantly honoured. Annual consent refresh.

The single test before any message goes out: “Would my friend who’s a dentist message me like this?” If no — kill it.

Part 4 — Staff-Facing AI Augmentation

4.1 Staff Roles + Time Lost to Manual Lookups

Estimated total recovery for a 4-doctor multi-disciplinary practice: ~70-90 staff-hours/week = 1.5-2 FTE redirected from clicking to caring.

4.2 Per-Touchpoint Information Cards (T-30 seconds)

What the staff member sees on their screen 30 seconds before the patient arrives:

Design rule: every card fits one Telegram message height (~10 lines max). Anything deeper = “tap to expand” link.

4.3 Automation Opportunities (the “AI does this so staff doesn’t have to” list)

Part 5 — The Doctor’s Command Surface

This is the heartbeat of specialist revenue. Doctor sees, signs, and tracks every rand.

5.1 Quote Lifecycle

Examination → AI drafts quote → Doctor reviews & approves
   → Sent to patient → Pre-auth submitted → Scheme decision
   → Patient acceptance → Scheduled → Treated → Billed → Paid

5.2 Quote Creation (Automated)

1. Doctor completes exam, dictates 30-second voice note: “Patient needs implants 36 and 46, sinus lift on 26, full arch graft. Crown on 11 needs replacing.”
2. AI parses → maps to ICD-10 + tariff codes (BHF / scheme codes)
3. AI builds line-item quote with codes, fees (per practice fee schedule), lab fees, materials
4. AI estimates medical aid coverage based on patient’s scheme + plan + remaining benefits
5. Quote drops into doctor’s approval queue within 60 seconds

5.3 Doctor Approval — Sample Telegram Card

[Quote #2026-0512]  PENDING YOUR APPROVAL

Patient: Mrs P. Naidoo (#1247)
Procedure: Implants 36, 46 + sinus lift 26 + crown 11
Total: R 87,450
  Pro fees:   R 62,100
  Lab:        R 14,800
  Materials:  R 10,550

Medical aid (Discovery Comprehensive):
  Likely cover:    R 23,000
  Patient owes:    R 64,450
  Patient's PMSA:  R 38,200 available

Flags:
  Smoker — implant success advisory attached
  Outside annual limit by ~R 9k

[ Approve ]  [ Modify ]  [ Reject ]  [ Defer ]  [ Open file ]

Tap Approve → quote PDF generated with doctor’s signature, sent to patient via WhatsApp + email, pre-auth lodged automatically with scheme, audit trail written.

5.4 Doctor’s Quote Dashboard (Telegram + web)

Pipeline view, one row per quote:

5.5 Escalation Rules

• Specialist authority: up to R 100,000
• Senior partner: R 100,000–R 300,000
• Practice owner: R 300,000+ or full-mouth rehabs
• Any quote involving sedation/GA: anaesthetist co-approval required

5.6 Doctor’s Daily Surface (Telegram)

Morning brief (07:15)

Today’s patient list with one-line histories, attention items, overnight cases needing review, lab fits, post-op concerns.

Quote approval queue

Persistent pinned message. Updates live. Each pending quote = inline buttons. Doctor clears queue between patients (~30 sec/quote).

End-of-day debrief (17:30)

Patients seen, billed, notes filed, quotes approved/sent/awaiting sig, flags worth knowing.

Quick-ask bot

“Show me Mrs Patel’s last PA” → image inline. “What did Dr Jones say about #1247?” → last note + author. “Last 3 implant cases I did on smokers” → mini table with outcomes.

Voice dictation

30-sec voice note → SOAP note + lab Rx + GP letter drafted in Telegram → Approve / Edit / Discard. ~48 min/day/doctor recovered.

Part 6 — Platform Recommendation

6.1 The Three Options

6.2 Recommendation by Architectural Layer

6.3 Captain’s “OpenClaw + Obsidian Brain Per Customer” Hypothesis

The Obsidian brain per customer half is correct and should be the centrepiece. The OpenClaw-as-platform half is misaligned with what OpenClaw actually is today.

OpenClaw is a code-writing crew with workspace governance — it shines at “given this task registry and this repo, write the migration, the API, and the tests.” It does NOT ship: a multi-tenant runtime, a patient memory schema, a WhatsApp channel, a doctor approval flow, a POPIA audit log, a quote tracker, a recall engine, or a no-show predictor. Every one of those would have to be built inside OpenClaw, against an architecture optimised for a different problem.

Production-readiness gap (8 things missing):

1. Multi-tenant isolation (today: single workspace volume)
2. Per-tenant secrets, OAuth tokens, key rotation
3. POPIA-compliant audit log + access control
4. Public ingress that isn’t SSH-tunnel-only
5. Channel adapters (WhatsApp Business Cloud, SMS, voice)
6. Patient/staff memory primitives — building Foothold inside OpenClaw
7. Stable container — volume-mount Coolify mismatch still open
8. Dental agent roster — current 7-8 agents are software engineering roles

Effort estimate to first dental tenant live:

6.4 Verdict

• Primary AI platform: Anthropic Claude (Sonnet 4.6 + Haiku 4.5) called directly from a per-tenant Node/TypeScript pod, with n8n as the workflow plane. This is the YBA Edge Foothold spec applied to dental, full stop.
• OpenClaw’s role: parallel track, not the dental vehicle. Keep it building YBAFlow / YBA Terra. Revisit only after (a) the volume-mount blocker is resolved, (b) it’s proven in YBAFlow, and (c) we have ≥3 dental tenants live and feel pain n8n can’t handle.
• Cost ceiling per practice tenant: R1,500/month all-in at typical specialist volume (~250 patients, ~600 WhatsApp turns/day, ~30 hr voice transcription). Breakdown: Anthropic ~R900 + Whisper ~R200 + infra ~R300 + headroom R100. Fits cleanly inside R8-15k/mo practice subscription with 85 %+ gross margin.
• Lock-in posture: vault is portable markdown, n8n workflows are JSON, only the Anthropic SDK call is provider-specific — swap to AWS Bedrock-Claude in <1 week if compliance ever forces it.

6.5 The One-Paragraph Honest Answer

If you ship Foothold-architecture for dental, you’d use Anthropic Claude as the brain, a per-patient markdown vault as the memory, n8n for the cross-system automation, WhatsApp Business Cloud API + a Telegram approval bot for the channels, and Postgres for the transactional plumbing — first practice live in roughly 30-45 engineer-days at ~R1,500/tenant/month LLM+infra. If you ship OpenClaw-as-product, you’d inherit a code-writing agent crew that today can’t be reached without an SSH tunnel, has an open volume-mount blocker, ships zero patient/staff/channel primitives, and would need 14-22 weeks of retrofit before tenant #1 — for which you’d still be calling Anthropic underneath. Pick A (Foothold + Anthropic + markdown vault) because OpenClaw isn’t a dental runtime. Keep OpenClaw doing what it does well — writing the code that builds YBAFlow — and let the dental product run on the architecture Captain already locked.

Part 7 — Production Plan

7.1 Pricing Tier for Dental Specialist Practices

Dental practices fit into the mid-tier of the YBA Edge ladder — between Foothold and Office Brain — at a vertical-specific price.

Why dental commands a premium over Foothold: higher integration burden (PMS API, scheme APIs, voice transcription, doctor approval bot), POPIA medical-data compliance work, vertical-specific knowledge (procedures, codes, scheme rules engine).

7.2 Architecture (Identical to Foothold + Dental Specialisations)

Per-practice pod on Hostinger VPS: - n8n-{slug} — workflow engine (recall, pre-auth chase, no-show prediction, day-end reports) - brain-{slug} — FastAPI + Anthropic SDK + markdown vault + per-channel adapters - tgbot-{slug} — Telegram bot for doctor approvals + staff briefs - wabridge-{slug} — WhatsApp Business Cloud API webhook receiver + router - emailbridge-{slug} — Gmail/Outlook OAuth listener + email triage + draft writer + send handler - voicepipe-{slug} — Whisper transcription pipeline (clinical voice notes)

Shared infra (across all practice tenants): - Postgres with schema-per-tenant + RLS + per-role isolation - Traefik wildcard cert *.tenants.ybaedge.com - Foothold Ops Telegram channel for monitoring - Anthropic shared org-level API key (volume aggregates faster)

Per-practice subdomain: {practice-slug}.tenants.ybaedge.com (e.g. matrixdental.tenants.ybaedge.com)

Per-practice vault structure:

/srv/tenants/{practice-slug}/vault/
├── CLAUDE.md                  (practice persona + scope cap + clinical guardrails)
├── practice/
│   ├── about.md
│   ├── fees.md                (fee schedule, scheme rules)
│   ├── staff.md               (staff directory)
│   └── procedures.md          (practice-specific procedure protocols)
├── patients/
│   ├── 0001-naidoo-priya.md   (one file per patient)
│   ├── 0002-pillay-anand.md
│   └── ...
├── staff/
│   ├── dr-bhamjee.md          (one file per staff — preferences, voice samples, notes)
│   └── ...
├── log/
│   └── {YYYY-MM-DD}.md        (daily activity log)
└── audit/
    └── {YYYY-MM}.md           (POPIA + clinical audit trail)

7.3 Build Order (30-45 engineer-days)

Phase 0 — Pre-build (Captain’s calls, Days 1-2)

• Approve dental as YBA Edge’s 2nd vertical (after EC farm)
• Approve R8,000/mo + R12,000 onboarding for the Matrix Dental Practice tier
• Approve target: first dental tenant live in 6 weeks
• Decide: Matrix Dental as pilot/case-study customer (warm intro from Captain) or different practice

Phase 1 — Foundation (Days 3-10)

Dental product reuses ~80 % of the Foothold tenant infrastructure. The Foothold Wave 1 build (provision_tenant.sh, tenant-brain, tenant-tgbot, vault template, Traefik wildcard cert) directly serves dental. Add to it:

• Whisper voice transcription pipeline (voicepipe-{slug} Docker image) — OpenAI Whisper API, accent-tuned for SA English
• WhatsApp Business Cloud API integration (wabridge-{slug}) — receive webhook → router → brain → reply
• Email bridge with Gmail/Outlook OAuth (emailbridge-{slug}) — triage + draft + send (tier-dependent)

Phase 2 — Dental specialisation (Days 11-25)

• Quote tracking + doctor approval bot — full pipeline (voice exam → AI quote draft → Telegram approval card → patient delivery → pre-auth submission → tracking dashboard)
• Pre-auth chasing automation — n8n workflow with scheme API integration (Discovery, Bonitas, Bestmed via Healthbridge BHF)
• PMS integration adapter — Dental4Windows / Elixir-Live / Healthbridge — pick whichever Matrix Dental uses
• Tariff + ICD-10 code rules engine — knows which codes need which auth, what schemes cover, gap calculation logic
• Patient vault schema — patient record markdown template, intake form generator, X-ray/CBCT image storage with DICOM viewer link
• Recall engine — specialty-specific cadence (perio 3-month, ortho retainer 12-month, implant annual, paeds 6-month, general 6-month)
• No-show prediction model — uses 6 weeks of historical appointment data (need to import from PMS)

Phase 3 — Patient-facing layer (Days 26-35)

• WhatsApp AI receptionist — booking triage, intake form via secure link, calendar invite generation
• Pre-consultation prep flow — mobile-friendly form, X-ray request from referring dentist, red-flag pre-screening (bisphosphonates, smoking, diabetes)
• Treatment plan + quote delivery — plain-English summary + clinical PDF, payment options, scheme breakdown
• Post-op companion — scheduled check-ins (4h/12h/24h/48h), red-flag detection, escalation
• Healing period messaging — clinical interval, “silence promised” line, optional photo submissions
• Recall reminders — three-option WhatsApp (book/remind/not-now), 12-month silence respected

Phase 4 — Staff-facing layer (Days 36-40)

• Receptionist screen-pop — caller-ID lookup, T-30s arrival cards, unified patient lookup
• Nurse chair-side tablet — tray list, allergy banner, lab arrival flags
• Practice manager morning brief + EOD KPIs — Telegram digest at 07:30 + 17:00
• Doctor’s daily surface — morning brief, quote queue, EOD debrief, quick-ask bot, voice dictation pipeline

Phase 5 — Go-live (Days 41-45)

• First practice (Matrix Dental or pilot) onboarded — 5-day playbook same as Foothold
• First WhatsApp AI receptionist live
• First doctor approval cycle in production
• First patient daily brief
• First post-op companion sequence
• First recall reminder cohort
• First no-show prediction running

7.4 What Captain Decides This Week

To unblock the dental track:

1. Approve dental as 2nd vertical after EC farm? (Y/N)
2. Pick the first dental tenant — Matrix Dental (warm intro needed) or a different practice from Captain’s network?
3. Approve R8,000/mo + R12,000 once-off Practice tier pricing? (Y/N — or modify)
4. Approve 30-45 day build window? (Y/N — or stage longer)
5. Approve OpenClaw stays parallel (YBAFlow build-layer, not dental product)? (Y/N)

7.5 Risks + Mitigations

Closing

Dental is the second YBA Edge Foothold vertical. EC farm proves the architecture for agriculture; Matrix Dental (or equivalent) proves it for medical-specialist practices. Same pattern: per-tenant pod, markdown vault, Anthropic + n8n + WhatsApp + Telegram.

The architecture is locked. The decisions Captain made yesterday on Foothold ALL APPLY to dental. What dental adds is vertical-specific code (PMS integration, scheme rules engine, voice dictation, quote tracking) — not architectural change.

~30-45 engineer-days from Captain’s go to first practice live. R8,000/mo per practice. 85 %+ gross margin.

Run the rhythm, sell the output, the system runs you.

— Niki / YBA Edge Strategy

Part 8 — Brand Strategy + Code-Reuse Architecture

8.1 The Brand Stack — Edge front, Engine behind

Three options evaluated. Pick: Option B (Co-branded “Powered by”).

Customer-facing brand is YBA Edge. The engine underneath is named, visible, and credited: YBA Med Engine (dental) and YBA Terra Engine (farm). One Edge invoice. Edge handles delivery, support, and the customer relationship. The engine brand quietly accrues equity from day one so when Med + Terra spin out as standalone products in 12-24 months, the brand isn’t a stranger — it’s been running in production with paying customers.

What customers see day one: - Contract header: YBA Edge (Pty) Ltd - Service line: “YBA Edge Practice tier — powered by YBA Med Engine” - Single invoice from Edge - Support via Niki/Edge Ops on Telegram + WhatsApp - Login screen: Edge logo top-left, “Powered by YBA Med Engine” footer

Launch day for YBA Med (12-24 months out): - Login screen flips: YBA Med logo top-left, “Brought to you by YBA Edge” footer - One-page contract addendum migrates billing to YBA Med (Pty) Ltd - Founding customers grandfathered at sign-up rate for 24 months (Matrix Dental locked at R6,000/mo for life) - Edge stays in the picture as the white-glove implementation partner

The brand transition reads as graduation, not bait-and-switch. That’s the whole point.

8.2 Dental Tier Name — YBA Edge Practice

Five candidates evaluated. Pick: YBA Edge Practice.

“Concierge” stays in reserve for the upsell tier (R12-15k/mo) once the product matures.

8.3 Code-Reuse Architecture — The Repo Structure (Non-Negotiable)

Captain’s instinct is right: build for reuse from day one or rebuild from scratch in 18 months. This architecture is mandatory:

yba-platform/
  packages/
    core/              # vertical-agnostic — 100% reuse across all YBA products
    med-engine/        # medical vertical — becomes YBA Med
    terra-engine/      # agricultural vertical — becomes YBA Terra
  tenants/
    matrix-dental/     # customer-specific config + overrides
    ec-farm/           # customer-specific config + overrides

Layer map

The Discipline

Any code that would fit in packages/core/ or packages/med-engine/ MUST go there, even when only one tenant uses it today. The moment tenant-specific code creeps into the engine layer, reuse dies quietly.

Reuse Targets

• Matrix Dental v1 → YBA Med v1: 70 % (35 % core + 35 % med-engine carry over directly)
• EC Farm v1 → YBA Terra v1: 65 % (35 % core + 30 % terra-engine)

These numbers require the repo discipline above. Without it, reuse drops to 20-30 % and Med launch costs an extra 6 months of engineering.

Part 9 — Staff + Doctor UI/UX Architecture

9.1 Interface Choice — PWA + Tauri Helper (Hybrid)

Four options evaluated:

Pick D. Ship the PWA at MVP. Add the Tauri helper in v1.1.

Why D wins: - PWA covers 90% of surface area (reception, dashboards, quote approvals, file drag-drop, messaging, transcripts) - Helper covers the 10% PWAs are bad at: continuous voice recording during 45-min consult, system tray notifications, drop-folder watcher - Tauri over Electron — 5-10 MB binary instead of 150 MB; Rust-based; signs cleanly; ~300 lines of Rust + WebSocket bridge - No multi-platform pain in v1 — Practice PCs are Windows; build a Windows .msi for the helper, ship PWA everywhere else - Captain’s “installed on staff PC” feel preserved — tray icon, system notifications, drop-folder watcher — all the OpenClaw-flavoured behaviour, without the OpenClaw tax

9.2 Universal Frame (every role, every screen)

+----------------------------------------------------------------------+
| Matrix Dental    Search: type a patient...    [+ New voice note]  Niki v |
+--------+-----------------------------------------------+-------------+
|  LEFT  |              MAIN CANVAS                       |   RIGHT    |
|  RAIL  |                                                |   RAIL     |
|        |   The active task lives here.                  | (collap-   |
| Role-  |   Patient card / treatment plan / consult      |  sible)    |
| based  |   recording / quote review / report.           |            |
| nav    |                                                | Telegram   |
|        |                                                | WhatsApp   |
|        |                                                | Activity   |
+--------+-----------------------------------------------+-------------+
| Sync: OK    Mic: idle    Notifications: 3    SAST 14:22              |
+----------------------------------------------------------------------+

9.3 Per-Role Navigation

Same shell. Different rail. One install.

9.4 Hard Rules — The Never-Do List

1. Never auto-record without explicit per-visit consent. Verbal or written. Logged.
2. Never auto-send a clinical document outside the practice without a human tick. AI drafts. Doctor signs. Always.
3. Never expose AI errors or uncertainty to the patient. “The AI thinks…” stays inside the practice.
4. Never store patient data outside the tenant’s vault. No shared buckets, no cross-tenant indexing.
5. Never let AI prescribe, diagnose, or alter clinical plans autonomously. Drafts only. Doctor signs.
6. Never hide the recording indicator. Red dot visible in the room when audio is captured.
7. Never let drafts auto-expire. Untouched drafts after 7 days bubble up to manager, not the bin.
8. Never assume a file’s patient. Below-threshold AI confidence → “Needs Filing” inbox, never auto-routed.
9. Never share compliance / audit data outside manager role.
10. Never block a doctor mid-consult with a UI dialog. Modals forbidden during a live consult.

Part 10 — Three Consult Flow Walkthroughs

10.1 Flow A — New Consult (45 min, implant assessment, GP referral)

T-15 min — Patient arrives - Receptionist’s screen shows today’s roster (n8n pulls from PMS at 06:00) - Patient taps in on reception tablet — name + DOB + last 4 of ID - Tablet: “Welcome, Mrs Naidoo. Dr Bhamjee will see you at 09:00. Please complete this short form.” Pre-fills from prior visits; only deltas needed - Intake + medical history update + recording-consent toggle on same flow - Signed PDF auto-files to /patients/{id}/intake/2026-05-04-intake.pdf - Reception tablet pings Ops Center: “Mrs Naidoo arrived 08:47. Forms complete. Consent: yes.”

T-3 min — Patient called through - Nurse’s chair-side iPad shows Patient Card: photo, age, allergies, meds, GP referral letter (auto-extracted to one paragraph), last 3 X-rays thumbnailed, alerts in red - AI-drafted “What this patient is here for” line: “Referred by Dr Pillay for assessment of #36 implant. BP medication noted. No flags.” - Nurse seats patient, takes BP, captures intra-oral photos (auto-named + filed by AI)

T-0 — Doctor enters room - Tablet shows Patient Card already open. Big green button: Start Consult - Beneath: 3 AI-prepared bullets — chief complaint, referral context, items to confirm

Consultation starts - Doctor taps Start Consult. Tablet plays soft chime audible to patient - Screen shows discreet red dot + “Recording for clinical notes — say ‘pause recording’ anytime.” - Recording-consent already captured at reception; doctor verbally re-confirms in 5 sec: “Mrs Naidoo, I’m recording our chat to draft your notes — okay?” Patient’s “yes” becomes part of audit trail

During consult - Doctor examines, talks naturally, says tooth numbers aloud: “#36 has lost the distal cusp, periapical shows adequate bone height, sinus floor 14 mm…” - AI silently: live transcribes, tags doctor vs patient vs nurse via voice fingerprint, flags clinical keywords (tooth numbers, ICD codes, drug names) - Nurse assists with retraction, suction, photos. No keyboard touched by anyone

End of consult - Doctor: “Okay Mrs Naidoo, I’ll send you a summary on WhatsApp shortly.” Taps End Consult - Tablet: “Processing — drafts ready in ~3 min.” Doctor walks out, washes hands, next patient

T+3 to T+5 min — Drafts appear - Doctor’s Telegram + web queue both light up: Mrs Naidoo — 5 drafts ready 1. SOAP note 2. Treatment plan (3 phased options: bone graft + implant + crown / short implant / bridge) 3. Quote with scheme codes + patient portion 4. GP letter to Dr Pillay 5. Patient WhatsApp summary

Doctor approves - Between patients (or end of session), doctor swipes through. Each: 2-line summary + full text expandable + Approve / Edit / Reject - Approve → n8n posts SOAP to PMS, submits pre-auth, queues GP letter, dispatches WhatsApp, books follow-up

Patient leaves - By the time Mrs Naidoo reaches her car: WhatsApp arrives. “Hi Mrs Naidoo — Dr Bhamjee here via Matrix Dental. Quick recap: we’re planning an implant for your lower-left back tooth. Step 1 is a small bone graft (60 min, R8,400 — your scheme covers R5,200). Step 2 in 4 months is the implant. Full plan PDF in 2 hrs. Reply HELP for questions.”

Background work (next 60 min) - Pre-auth submitted to scheme - Treatment plan rendered as PDF, emailed + filed to vault - GP letter sent to Dr Pillay - Follow-up provisionally booked for bone-graft slot in 2 weeks - KPI counter: 1 new consult, R-value of plan, conversion-pending state

10.2 Flow B — Procedure Visit (90 min, implant placement)

Same arrival → nurse prep flow, but tablet shows pre-op checklist (prophylactic antibiotic taken? fasting? driver arranged? Each ticked → green).

During procedure — doctor in landmark mode: narrates only key moments (“flap raised at 09:12, osteotomy 3.5 mm, implant torqued to 35 Ncm, batch ABC123…”). AI listens passively, doesn’t try to transcribe small talk. Nurse takes intra-op photos at 4 milestones; AI auto-tags + files.

End — doctor says “closing up, 4-0 vicryl, healing abutment placed.” Taps End.

T+5 drafts: surgical note, post-op instructions sheet (tailored: implant + bone graft + smoker yes/no), Rx (amoxicillin + ibuprofen + chlorhexidine), follow-up at 7 days, lab Rx if applicable.

Doctor approves Rx with biometric tap → script PDF + WhatsApp to patient + faxed to chosen pharmacy via n8n.

Patient leaves with: printed post-op sheet (also on WhatsApp), Rx already at the pharmacy, cold-pack reminder set, follow-up booked.

10.3 Flow C — Follow-up Review (15 min, 4-week post-op)

Quick check-up. Nurse pre-loads surgical note + post-op photos for comparison side-by-side.

Doctor narrates briefly: “Healing well, no swelling, sutures dissolved, occlusion checks out, ready for impressions in 2 weeks.”

End at minute 12. Drafts: short progress note, next-stage booking (impression), patient WhatsApp confirming next visit, no quote update needed.

One-tap approve. Done.

10.4 AI Processing Pipeline — End-to-End Timing + Cost

Total: ~70 sec end-to-end · ~R7.20 in API spend per consult. Drafts ready well within 5 min.

10.5 Time Saved Per Consult

Per doctor: 12 consults/day × 42.5 min = 8.5 hours/day saved. Per week: ~42 hours per doctor per week. Across 3 specialists + GP + hygienist: ~210 hours/week of staff time freed.

The real win isn’t billed hours — it’s that the doctor’s hands stay on the patient, not the keyboard.

Part 11 — n8n-First Architecture

11.1 The Architectural Rule

n8n owns workflows, integrations, cron, webhooks, retry logic, and any glue between systems. Custom code is reserved for: (1) real-time UI components, (2) latency-critical agent loops with tool-use, (3) protocol-level work n8n cannot do natively. Anything that can be expressed as “trigger → call API → transform → call API → store result” belongs in n8n.

11.2 The n8n Workflow Library — 29 Core Flows

A. Patient Communication Workflows (12)

B. Staff Workflows (11)

C. Background/System Workflows (6)

Total: ~29 core flows + ~10-15 utility flows = ~40-45 n8n flows total for dental v1.

11.3 The Custom Code Surface (6 components, ~5,000 LOC)

Total: ~5,000-7,000 LOC for dental v1.

11.4 Target Ratio

~85 % n8n flows + AI prompts. ~15 % custom code.

Strip the PWA out and it’s roughly 80 % n8n / 20 % custom.

11.5 Why n8n-First Wins (vs custom-everything)

Time recovered: 60-105 engineer-days = 2-5 months of build time. Beyond raw time, n8n-first means: every workflow is a diagram Captain can read; flows can be edited without a deploy; failure is visible in execution log instead of buried in stack trace.

11.6 Where AI Lives (per capability)

Daily AI cost per tenant: $3-7/day (~R55-130/day). Monthly: R1,650-3,900. Caps enforced by anthropic-cost-monitor (C3).

Part 12 — Production Plan (Locked, 30-45 Days)

12.1 Phase 1 — Foundation + Walking Skeleton (Days 1-15)

Custom code: - tenant-brain — chat + vault read/write (minimum viable) - tenant-wabridge — Meta webhook + media download - tenant-tgbot — basic relay + approval keyboard - staff-pwa — schedule view + patient card only

n8n flows: - A1 booking-confirm, A2 reminder-T7, A3 reminder-T24, A12 patient-inbound-triage - B1 morning-brief, B2 patient-arrival-checkin - C1 pg-backup, C2 vault-git-sync, C4 container-healthcheck

Goal: practitioner-client takes bookings, receives reminders, gets AI WhatsApp triage, sees morning brief.

12.2 Phase 2 — Clinical Workflow (Days 16-30)

Custom code: - voicepipe — full Whisper + diarisation - scheme-rules-engine — top 50 dental procedures mapped to codes - staff-pwa — voice capture + alerts + drag-drop

n8n flows: - A4 preconsult-form, A5 arrival-info, A6 quote-and-plan-delivery - A7 preauth-status, A8 postop-companion, A9 healing-period - B5 voice-consult-pipeline, B6 quote-approval-loop - B7 preauth-submit, B8 preauth-chase - C3 anthropic-cost-monitor, C5 scheme-api-status

Goal: doctor records voice exam → AI drafts quote → Telegram approval → patient delivery → pre-auth submission. End-to-end clinical loop live.

12.3 Phase 3 — Polish + Lifecycle (Days 31-45)

Custom code: - staff-pwa — KPI dashboard, full reporting, reception screen pops - tenant-brain — practice voice tuning per tenant

n8n flows: - A10 recall-reminders, A11 birthday - B3 inbound-call-screenpop, B4 lab-arrival-scan - B9 eod-kpi-compile, B10 stock-low-alert, B11 popia-consent-expiry - C6 wa-delivery-aggregation - All utility flows + error handlers

Goal: v1 complete. Recall lifecycle running, full reporting, reception experience polished, POPIA-compliant.

12.4 Tauri Helper — v1.1 (Days 46-60)

After Matrix Dental is live on the PWA, add the desktop helper: - Windows .msi installer - Continuous voice recording (offline-first buffer) - System tray + notifications - Drop-folder watcher (paper-scan workflow) - WebSocket bridge to PWA

~300 lines of Rust. Captain’s “OpenClaw-like installed feel” delivered.

Closing Note for Captain

The product writes itself if we hold three lines:

• One shell, one install, role-aware rails. Staff learn the app once, not five times.
• AI drafts, humans dispatch. Every clinical artefact has a human tick before it leaves the building.
• n8n is the nervous system, not the spinal cord. Custom code is the spine — small, sturdy, replaceable. Flows do the talking.

Matrix is the proof. Once dental flows are dialled in, the Edge Med vertical template is 80% reusable for the GP practice, the optometrist, the physio. That’s the empire move.

Build for reuse from day one (packages/core/ + packages/med-engine/ + tenants/matrix-dental/). When YBA Med launches as a standalone product in 12-24 months, 70% of Matrix’s code is already YBA Med’s code — not a rewrite.

— Niki / YBA Edge Strategy

Round 3 Decisions — Locked

Captain’s confirmed decisions from Round 3 (2026-05-07). These are now binding for the build.

Part 13 — PC Interface — Final Verdict (After Specialist Deep-Dive)

Captain held Q14 in Round 3 with the request: “I don’t need install feel, I just need clean and accessible — get specialists to tell me the right answer.” This is that answer.

13.1 The Verdict

Pick Option C: PWA + tiny Tauri tray helper.

Browser-only is the wrong answer for dental specifically. Not because of “install feel” — because a 45-90 minute voice consultation is the spine of the entire AI pipeline, and browsers cannot be trusted to hold a recording for that long. Everything else (clean UI, no install friction for 95% of usage) is preserved because staff live inside the PWA. The helper is a 5-10 MB invisible insurance policy.

13.2 The Honest 19-Capability Reality Check

Of the 19 capabilities the staff/doctor interface must deliver:

• 13 work fine in browser ✓ (schedule, patient cards, AI drafts, dashboards, multi-monitor, role views, audit log, etc.)
• 3 are clinical dealbreakers for browser-only ✗
• 3 are daily-friction problems ⚠ (file watcher, X-ray launch, screen-pop)

The three clinical dealbreakers

1. 45-90 minute voice recording. MediaRecorder pauses/dies when: tab backgrounded on mobile Safari, screen locks, browser crashes, OS sleeps, another tab steals mic. “You find out at 17:00 that 12 minutes of crown prep are missing” — entire AI pipeline degrades from magic to garbage the first time a recording cuts at minute 38.
2. Notifications when app closed. Web Push only fires if the browser process is running. Manager closes Chrome at 17:00 → urgent WhatsApp at 19:00 from anaesthetist “patient is on warfarin, do not proceed” missed until tomorrow. Clinical risk.
3. Offline-first recording. SA internet drops. Service Worker can cache UI but a 90-min audio blob in IndexedDB is fragile (quota, eviction, no guarantee). Helper writes to disk — no quota worries.

13.3 Three Real-World Scenarios

13.4 Captain’s “Don’t Care About Install” — Resolved

Captain’s exact words: “I don’t care about install feel, I need the best solution.”

That sentence eliminates “browser-only” and “PWA-only” from contention. The only reason to pick those was to avoid the install. If install isn’t a concern, the question collapses to: “What’s the most reliable interface for dental clinical workflow?” — and on reliability, browser-only fails three dealbreakers.

The point was never install feel. The point is whether a 90-minute consult survives an OS sleep event. Browser says “probably.” Helper says “yes.”

13.5 Cost / Time

Delta C vs A: ~20-25 engineer-days. That’s 4-5 weeks for an engineer. For a product where the recording layer is the core moat, that’s the cheapest insurance you’ll ever buy.

Tauri specifically (not Electron): 5-10 MB binary, Rust-based, signs cleanly on Windows, mature auto-updater. Code-signing cert ~R5,500/yr (DigiCert / Sectigo) + 2-4 weeks Defender reputation seasoning.

Part 14 — Repo Structure with Examples (Non-Technical Walk-Through)

Captain held Q15 with the request: “Explain this with examples please before I make a call.” Plain English, with concrete examples.

14.1 The Restaurant Kitchen Analogy

Imagine you’re opening a restaurant group. You start with one Italian place (Matrix Dental). Eighteen months from now you want to open a steakhouse (YBA Med) and a sushi bar (YBA Terra) too.

Three things in any kitchen:

1. The basics — knives, stoves, fridges, the till system, the booking software. Identical across all three restaurants.
2. The cuisine knowledge — how to make a proper Italian ragu vs how to butcher a ribeye vs how to break down a tuna. Different per cuisine, but the same for every Italian place you’ll ever open.
3. The customer-specific bits — this Italian uses Nonna’s secret family sauce. That one is in Sandton so prices are 30% higher. This chef hates basil.

Three drawers. Don’t mix them up. If Nonna’s sauce ends up in the standard ragu recipe book, when you open Italian #2 you accidentally inherit Nonna’s recipe — or worse, you can’t open Italian #2 without unpicking Nonna’s recipe out of the standard one.

That’s the whole proposal.

14.2 What Goes In Each Folder — Concrete Examples

packages/core/ — the basics (every YBA product uses these)

• whatsapp-adapter.ts — sends + receives WhatsApp messages. Matrix uses it for patient comms. EC Farm uses it for staff alerts. Future Realty uses it for tenant messages. One implementation. Everyone imports it.
• vault-retrieval.ts — opens markdown brain files (patient notes, farm logs, deal pipelines). Same code regardless of what’s in the markdown.
• tenant-isolation.ts — keeps Matrix’s data invisible to EC Farm. Universal need.
• auth.ts / audit-log.ts / billing.ts — every product needs these
• telegram-bot-base.ts — foundation for every YBA Telegram bot
• n8n-flow-loader.ts — registers n8n workflows for a tenant

“Build it once, every product on the platform gets it for free.”

packages/med-engine/ — medical/dental cuisine knowledge

• scheme-rules-discovery.ts / scheme-rules-bonitas.ts — knows how each scheme processes pre-auth. Same answer for tooth or knee.
• icd10-codes.ts — SA ICD-10 diagnosis code lookup
• tariff-codes.ts — BHF tariff codes
• patient-record-schema.ts — shape of a patient record
• voice-transcription-medical.ts — Whisper tuned for medical vocab (knows “amoxicillin” not “a mock sissilin”)
• popia-medical-logging.ts — POPIA audit for protected health info
• consent-management.ts — recording, treatment, POPIA consent

“Medical knowledge that’s the same whether you’re a dental specialist, a GP, or a physio. Build once.”

packages/terra-engine/ — agricultural cuisine knowledge

• location-hierarchy.ts — recursive farm → tunnel → section → board (works for greenhouses, fields, fish tanks)
• cohort-tracking.ts — batch tracking for crops, fish, livestock
• water-quality-logging.ts — pH, EC, DO, temperature
• seasonal-recall.ts — what’s planted when (per SA agri season)

“Farming knowledge. Same answers for aquaponic, hydroponic, livestock. Build once.”

tenants/matrix-dental/ — Matrix only

• fee-schedule.json — Matrix’s pricing per procedure
• staff-roster.json — Dr Bhamjee, Haffajee, Vorster, Mayet, Chrismarié
• branding.json — Matrix logo + colours
• quirks.md — “Dr Vorster prefers Romexis over Sidexis” / “Reception always offers tea, never coffee”
• whatsapp-config.json — Matrix’s WA Business number + working hours
• referral-network.json — overflow hygienist contacts

tenants/ec-farm/ — EC Farm only

• cultivar-plan.json — Lollo Rossa + Salanova + Butterhead per the locked plan
• tunnel-config.json — 6 tunnels × 2 sections × 96 boards
• staff-roster.json — Farm Manager + Labourer
• pricing.json — founding-customer R0-R1,200/mo

14.3 Why This Matters — Two Stories

Scenario X — Discipline Held. Niki builds Matrix in 2026. WhatsApp adapter in packages/core/. ICD-10 lookup in packages/med-engine/. Matrix’s fee schedule in tenants/matrix-dental/. Eighteen months later, YBA Med launches as standalone. Niki creates new repo, copies two folders across, customises login screen. YBA Med v1 ships in 3 weeks.

Scenario Y — Discipline Broken. Niki builds Matrix in a hurry. WhatsApp adapter at tenants/matrix-dental/whatsapp.ts. ICD-10 hardcoded into Matrix’s quote-drafting. Fee schedule tangled with scheme rules. Eighteen months later, YBA Med launches. Every file inspected line-by-line: “Is this Matrix-specific or universal? Is Dr Bhamjee’s name in here?” 6 months of untangling before YBA Med ships.

Cost of breaking discipline: ~5 months of engineering wasted on something that should have been free.

14.4 What “Lift and Shift” Actually Looks Like

When YBA Med launches as a standalone product, the migration is literally:

# In the new YBA Med repo
cp -r yba-platform/packages/core      ./packages/core
cp -r yba-platform/packages/med-engine ./packages/med-engine

# Done. YBA Med v1 has 70% of its code already written.

Customer-facing change: login screen + logo. Same code underneath. Matrix carries on as YBA Edge customer with zero downtime. New YBA Med customers (a GP, a physio) sign up directly to YBA Med with fresh tenants/{their-practice}/ folders.

On launch day for YBA Med, we copy two folders. That’s the migration.

Part 15 — Production Plan Stress Test (Dev Team Review)

Honest review by senior dev specialist. Captain prefers truth over politeness. Here’s what’s missing or optimistic in the plan.

15.1 TL;DR

The plan is directionally right but optimistic on calendar days and silent on three structural risks: PMS integration (vendor unknown), Healthbridge BSP onboarding (4-6 week external lead time), and voice accuracy on real SA dental consults (untested). 30-45 day estimate is engineering-time only — ignores external dependencies, training, compliance paperwork, soak/parallel-run period. Realistic ship: 55-70 days from Day 0.

15.2 Eight Hidden Risks

15.3 Nine Missing Build Steps

Not in Phase 1/2/3, must be added:

1. Day 0-3 Discovery Week — PMS audit, scheme audit, staff interviews at Matrix, Whisper benchmark
2. Day 0 Healthbridge BSP application
3. Day 0 Anthropic Enterprise / DPA negotiation
4. Day 0-5 POPIA Data Processing Agreement (Captain + lawyer, consent forms)
5. Day 0-7 Secrets vault setup
6. Day 25-28 Whisper accuracy spike (gates Phase 2 voice→quote flow)
7. Day 35-40 Staff training material + on-site session
8. Day 38-42 Pen-test / security audit
9. Day 42-45 Practice manager handover playbook

15.4 Critical-Path Dependencies

Day 0 ──┬─→ PMS audit ───→ Day 5 PMS adapter scoped → Day 10 built → Day 20 quote flow integration
        │
        ├─→ Healthbridge BSP application ─────────────────────→ Day 30-35 BSP creds → Day 40 pre-auth live
        │   (4-6 week external lead — BLOCKING for v1 if not started Day 0)
        │
        ├─→ Anthropic Enterprise / DPA ──────────────────────→ Day 25-30 ZDR + Tier 5 active
        │   (3-4 week negotiation)
        │
        ├─→ POPIA legal pack ─→ Day 7 consent forms + DPA signed → Day 10 intake flow can go live
        │
        ├─→ Whisper accuracy spike ─→ Day 3 transcription engine chosen → Day 12 voicepipe built
        │
        └─→ Code-signing cert (Tauri) ─→ Day 14 cert issued → Day 21 helper signed → Day 28 Defender reputation seasoned

Dependencies that push 30-45 day plan to 60-75 days if not started Day 0: 1. Healthbridge BSP (4-6 weeks) 2. Anthropic Enterprise tier (3-4 weeks) 3. PMS adapter if no API exists (7-15 dev-days hidden cost) 4. Code-signing reputation seasoning (2-4 weeks)

15.5 Timeline Reality Check

Niki’s recommendation: quote Matrix 60 days from Day 0 to go-live, with a soft target of 50 if Discovery clears clean. Underpromise, overdeliver — Matrix is the founding reference; their experience sets the YBA Edge brand.

15.6 Three Questions Captain Hasn’t Been Asked

1. Implementation lead — Captain solo blocks every other YBA project for 2 months. Hire junior dev (R25-40k/mo) or contractor (R600-900/hr part-time)?
2. Support SLA — what does R6,000/mo actually buy Matrix? Business hours? 24/7 P0? On-call rotation?
3. Rollback criteria — define kill criteria now, while we’re calm. “If at Day 60 the system has > 2 P0 incidents/week or staff CSAT < 6/10, we revert and refund.”

Part 16 — Business Strategy Refinement

16.1 Full Price Ladder (Customer #4 Onwards)

Founding 3 (Matrix + 2 peers): R6,000/mo + R5,000 onboarding for life.

16.2 Customer Acquisition Channel Mix

Pipeline target: 6-10 qualified conversations active at any time to hit ~17 paying practices in 12 months post-Matrix.

Founder-led sales for the first 20. Captain personally takes every demo until customer #20.

16.3 Scaling Plan — 1 → 5 → 20 Practices

16.4 Position vs GoodX — Co-Existence Wedge

Positioning statement for sales:

“GoodX runs your billing. YBA Edge Practice runs your practice. We don’t replace your scheme submitter on day one — we sit alongside it, capture every consult by voice, build your quotes, message your patients on WhatsApp, and brief you every morning on what matters. Your practice manager keeps GoodX for what GoodX does well. They get YBA for everything GoodX never did.”

This is co-existence, not rip-and-replace. Earn the right to replace GoodX after 18-24 months when YBA Med ships full scheme submission.

Where we win: AI scribing, voice consult capture, WhatsApp patient comms, pre-emptive recall, modern UX, AI-built quotes + pre-auth, vendor consolidation.

Where GoodX wins: scheme integration depth (30 yrs of edge cases), practice manager mindshare, compliance + audit trail maturity, support footprint (national reps), accountant-friendly reports.

16.5 12-Month Revenue Projection

Year 1: ~R870k recurring + ~R202k onboarding = ~R1.07M top-line, 62-64 % gross margin.

16.6 If Matrix Doesn’t Sign — Backup Plan

Backup specialist practices to approach (in priority order):

1. High-volume orthodontic practice in Sandton or Bryanston
2. Maxillofacial + oral surgery practice affiliated with Netcare or Life
3. Multi-disciplinary dental group in Cape Town
4. Periodontics practice in Pretoria
5. Paediatric dentistry practice

Hard rule: if no signed contract by Day 90 from Matrix’s first conversation, Captain personally pivots to backup #1. Keep building infra at 80% speed in the meantime — 80% of the platform is generic, 20% is specialty-specific.

Part 17 — Marketing Strategy

17.1 The 30-Second Pitch

Three versions evaluated. Pick: Version C (Differentiated, co-existence).

“Quick question — what’s your practice management system? GoodX, Elixir, Dental4Windows? Right. We don’t replace any of those. YBA Edge Practice is the AI concierge layer that sits on top — handles the patient comms and admin your PMS was never built for. Matrix Dental in Cape Town is our pilot site. R6,000 a month, no PMS migration, no risk. Can I send you a one-pager?”

Why C wins: opens with a question (signals respect), pre-empts the #1 objection (“I’m not switching off GoodX”), anchors on a real local reference, states a public price (SA specialists distrust hidden pricing), ends with low-commitment ask.

17.2 The 5 Core Marketing Assets

17.3 Launch Sequence — Months 1-6

Cumulative target by end of Month 6: 5-10 paying practices.

17.4 Trust Accelerators (Pick 5)

1. POPIA + HPCSA documentation upfront (2-page compliance doc linked from homepage)
2. “We don’t replace your PMS” positioning everywhere (every asset, every pitch)
3. Public pricing (R6,000 founding / R8,000 standard published on website)
4. Matrix Dental as living reference (principal willing to take 15-min calls from prospects)
5. Clinical advisory board (1-2 respected SA dentists endorsing the platform by Month 6)

17.5 Anti-Marketing Rules — What NOT to Do

• ❌ “AI for healthcare” generic pitches → ✓ Name the specific admin pain
• ❌ “Switch from GoodX!” PMS-replacement messaging → ✓ “Sits alongside your PMS”
• ❌ “Revolutionary,” “disruption,” “game-changer” → ✓ Plain language
• ❌ Multi-touch automated email sequences (5+ touches) → ✓ Maximum 2 touches, hand-researched
• ❌ Cold LinkedIn DMs without warm intro → ✓ Content + comments first
• ❌ Paid influencer marketing → ✓ Peer letters from real customers
• ❌ Webinars > 45 min → ✓ 30-min webinar + 15-min Q&A
• ❌ Hiding the price → ✓ Public R6k / R8k on site
• ❌ Asking for “just a quick demo” early → ✓ Lead with 1-pager + calculator. Demo is earned.

17.6 First 90 Days Marketing Targets

Realistic Month 3 outcome: 1 signed contract beyond Matrix. Month 6: 5-10 paying practices.

Round 4 Decisions — Locked

Captain’s confirmed decisions from Round 4 (2026-05-07). Almost all locked; one term needed plain-English clarification (Q30 — see Part 18 below).

Part 18 — Plain-English Glossary (Q30 Clarification)

Captain’s note on Q30: “I don’t understand what rollback means and P0 is or CSAT”. Locking that decision properly needs the words explained first. Here they are.

18.1 What “rollback” means

Rollback = if Matrix’s experience with YBA Edge Practice goes badly enough, we admit the project failed at this practice, switch them back to whatever they were using before (GoodX or whichever PMS), refund their money, end the contract clean, and learn from it for the next practice.

The opposite of rollback is “we keep going even though it’s not working” — which is how SaaS startups die. Defining rollback rules before launch protects both sides:

• Protects Matrix — they know we won’t trap them in a broken system out of pride
• Protects YBA Edge — we end clean before reputational damage spreads through the dental peer network

Without a rollback rule, the temptation is always to say “give us another 2 weeks” — and 2 weeks becomes 6 months and the customer is now miserable but locked in. This is how brands get killed.

18.2 What “P0” means

P0 = “Priority Zero” incident = the most serious kind of problem in software. Different teams use slightly different definitions; for our context:

• P0 = the system is genuinely broken in a way that affects clinical or financial work. Examples:
  • Voice consult recording stops working entirely
  • Patient WhatsApp delivery fails
  • Quote drafts can’t be sent to patients
  • Pre-auth submission to Discovery is broken
  • Doctor can’t approve quotes
  • Database corruption / data loss event
  • Whole system down
• P1 = serious bug but workaround exists (e.g. one specialist can’t get morning brief but the others can)
• P2 = minor bug, low impact (e.g. typo in a digest email)
• P3 = polish issue (e.g. button alignment off)

The proposed strict rollback rule said: “If we hit > 2 P0 incidents per week, that’s our signal that the system isn’t ready and Matrix should go back to their old PMS.” That’s a clinical-grade threshold — appropriate for a medical product because a P0 in dentistry can mean a missed pre-auth = lost revenue, or a missed alert = patient complication.

18.3 What “CSAT” means

CSAT = “Customer Satisfaction” score. A 1-out-of-10 rating you ask customers periodically.

How it works: every month or so we send a short survey to Matrix’s staff: - “How would you rate YBA Edge Practice this month from 1 (terrible) to 10 (excellent)?” - “Would you recommend it to a peer practice? Yes / No / Maybe” - “What’s the one thing you’d change?”

The proposed strict rule said: “If staff CSAT drops below 6/10 at Day 60, the system isn’t earning its keep — roll back.”

A CSAT of 6 means “okay, but not impressed.” Below 6 means actively unhappy. We can’t ask Matrix to keep paying R6,000/mo for “not impressed” — it’s bad for them and bad for the brand.

18.4 What the “strict” criteria actually mean (in plain words)

“At Day 60 from Matrix go-live, we run a checkpoint. If during the previous 7 days the system has had more than 2 critical incidents (where clinical or financial work was broken), OR if staff are rating the system below 6 out of 10, we admit it’s not working, switch Matrix back to their old system, refund whatever they’ve paid, and end the contract.”

Round 5 will re-ask Q30 with this plain-English version so Captain can confirm with full understanding.

Part 19 — “Captain Solo” Implementation — Implications

Captain picked Q28 = “Captain solo” for the Matrix build. Niki is documenting what that actually means so Captain can see the trade-off and adjust in Round 5 if needed.

19.1 What Captain Solo means in calendar time

• Discovery Week (Days 0-3): Captain on-site at Matrix, PMS audit, scheme audit, staff interviews, sample consult recordings → ~3 days Captain time
• Phase 1 (Days 4-15): Foundation build — tenant-brain + tenant-tgbot + tenant-wabridge + PWA shell → ~12 days Captain time, full-time
• Phase 2 (Days 16-30): Clinical workflow — voicepipe + scheme-rules-engine + voice-consult-pipeline + quote-approval-loop → ~15 days, full-time
• Phase 3 (Days 31-45): Polish + lifecycle — KPI dashboard + recall + reception screen-pop → ~15 days, full-time
• Days 46-55: Tauri helper (PWA + tray) → ~10 days
• Days 56-60: Soak week + go-live + Captain on standby for first 7 days post-launch

Total: ~60 calendar days of Captain at >80% capacity on Matrix.

19.2 What gets paused

19.3 Trade-off summary

Captain solo benefits: - R0 cash spend on dev (vs R30-40k/mo junior or R600-900/hr contractor) - Captain is the only person who fully understands the empire architecture — keeps the dental code aligned with future YBA Med vision - No onboarding tax on a new hire mid-build

Captain solo costs: - ~60 days of zero new strategic work for the empire - Foothold infrastructure for EC farm conflicts (Matrix vs EC priority) - If Captain falls sick / family emergency / loadshedding marathon — entire Matrix delivery slips - Captain personally on the hook for all support during build (no second human on call)

19.4 Sequencing question

Round 5 will ask Captain: build Foothold infra for EC farm FIRST (~10 days), then 60-day Matrix solo build? OR: Matrix first, EC farm waits ~70 days? OR: smaller Matrix scope to free Captain for EC farm in parallel?

This question matters because EC farm has been promised Foothold customer #1 status, and Captain has already sent the Partnership Proposal + Plant Operations Pack + SOP to her. Sliding EC farm by 70 days has trust implications.

Round 5 Decisions — Locked (and one challenged)

Captain’s confirmed decisions from Round 5 (2026-05-07). 7 locked + 1 challenged that Niki agrees needs revising.

Part 20 — Captain’s Q39 Challenge + Revised Rollback Framing

Captain’s exact challenge: “why do you recommend revert and refund why not fix and continue seeing this is a startup and we know there will be problems in the beginning and Matrix will be paying less in order for us to learn fix and improve.”

20.1 Captain is right

The strict “> 2 P0/week → revert + refund” criteria from Round 4 was the wrong framing. It was an enterprise-SaaS reflex — appropriate for a customer paying full price expecting flawless service. Matrix is none of that:

• Matrix is a founding customer — explicitly part of building the product, not just consuming it
• R6,000/mo for life — below the R8,000 standard tier, with R5,000 onboarding (vs R12,000 standard) — this is a discount in exchange for bug tolerance, not a lower price for the same expectations
• Existing trust relationship — Captain knows Dr Bhamjee, this isn’t a stranger contract
• Industry-first — there is no SA dental practice running an AI workflow at this depth; bugs in months 1-3 are inevitable, expected, and the entire reason a pilot exists

The right framing is “fix and improve” as default — rollback is a last-resort emergency exit, not a calendar-driven trigger.

20.2 Revised Rollback Framing

Default mode: FIX AND IMPROVE

• Bugs are expected and welcomed (they are the data)
• Weekly check-ins between Captain and Dr Bhamjee — open, no spin
• Monthly informal NPS-style “what’s working / what’s not” survey to staff
• Each P0 incident is a fix-and-prevent ticket, not a strike
• Each “this doesn’t suit our workflow” is a feature request, not a complaint
• The product matures with the customer — that’s the whole point of a pilot

Rollback triggers — only TWO scenarios

Trigger 1 — Catastrophic data event (automatic): - Patient data leak (POPIA breach with Information Regulator notification) - System data loss > 24 hours that can’t be recovered - Scheme submission fraud accusation against the practice - HPCSA / Information Regulator regulatory action

→ Mandatory rollback within 48 hours. Matrix reverts to old PMS. YBA Edge does NOT get to “fix and continue” — the regulatory environment requires us to step away. Refund of unused subscription fees, NOT onboarding fees.

Trigger 2 — Mutual decision (negotiated): - After 90 days, Captain + Bhamjee both agree the pilot isn’t delivering - Either side can call it without explanation - 30-day wind-down period - Refund of last paid month, pro-rata - Onboarding NOT refunded (work was done)

What is NOT a rollback trigger

• Bugs (P0/P1/P2/P3) — fixed, not refunded. Track them, prioritise by severity, ship fixes weekly.
• Staff dissatisfaction at 30/60 days — surfaces in NPS, becomes input to next sprint, not a contract break
• Workflow misfit — adjust the workflow, don’t end the contract
• Scheme rejections — fix the codes, don’t end the contract
• Voice transcription accuracy issues — tune the model, don’t end the contract

Founding-customer language for the contract

This goes in the Matrix-specific terms (separate from the standard Service Agreement):

*“Matrix Dental Specialist is YBA Edge Practice’s founding dental customer. In exchange for the lifetime R6,000/mo founding rate (vs R8,000 standard) and the R5,000 onboarding (vs R12,000 standard), Matrix commits to:

1. Weekly feedback sessions with Captain Richard during Months 1-3
2. Monthly informal satisfaction survey across all staff
3. Tolerance for bugs and rough edges during the pilot period
4. Permission to use Matrix’s experience as a published case study (with prior approval of specific content)

In exchange, YBA Edge commits to:

1. Same-week fixes for P0 incidents (system genuinely broken in ways that affect clinical or financial work)
2. Within-month resolution for P1/P2 issues
3. Public roadmap visibility — Matrix sees what’s coming next and influences priorities
4. The R6,000/mo rate locked for life — never increases regardless of YBA Med standalone product launch
5. Regulatory escape clause — if any catastrophic data event or regulatory action occurs, mandatory rollback within 48 hours with refund of unused subscription fees”*

This is partnership language, not service-vendor language. It matches the actual relationship.

20.3 What this changes downstream

• Q31 Support SLA stays. Business hours, 4hr response is still right — that’s about Captain’s time, not Matrix’s tolerance.
• Marketing position changes. When Captain pitches dental customer #2, the right line isn’t “we have a strict SLA + rollback rule” — it’s “Matrix has been with us for 6 months; here’s what they think; same partnership offer for the next 2 founding customers.”
• Customer #4 onwards gets standard service-agreement terms (no founding partnership rights) — different model.

20.4 Where we are in the planning loop

After Round 6, the dental case study is LOCKED. Niki has only one open question (Q47 — confirming the revised rollback framing) plus a small operational lock-in question (Q48). Once those clear:

• Document body is final
• Captain executes EC Foothold first
• After EC signs + Foothold live, Day 0 triggers Matrix Discovery Week
• 60-day build to Matrix go-live
• Monthly check-ins per the founding-customer agreement
• Customer #2 conversation happens Month 3 with Matrix as case study

🔒 PLAN LOCKED — 2026-05-07

All 38 decisions across 6 rounds confirmed by Captain. The dental case study is now the binding execution plan. Niki proceeds with the build per the locked architecture.

Round 6 Final Locks

Part 21 — Execution Kickoff

The dental case study is LOCKED. Here is what happens next, in order, with owners and dates.

21.1 The Sequence

TODAY ─→ EC farm Foothold infrastructure build (~10 days, Captain solo)
                           ↓
        EC farm Partnership Proposal signed by EC owner
                           ↓
        EC farm Foothold tenant provisioned + first daily brief delivered
                           ↓
        Matrix Discovery Week (Day 0-3): PMS audit, Whisper benchmark,
        scheme audit, staff interviews, voice fingerprint enrolment
                           ↓
        Matrix Phase 1 build (Days 4-15): foundation
                           ↓
        Matrix Phase 2 build (Days 16-30): clinical workflow
                           ↓
        Matrix Phase 3 build (Days 31-45): polish + lifecycle
                           ↓
        Tauri tray helper (Days 46-55) + soak week
                           ↓
        Matrix go-live (Day 60 from Discovery Week start)
                           ↓
        Month 3: case study captured + dental peer outreach begins

21.2 Captain’s Immediate Action List (Today + Days 1-14)

21.3 Niki’s Immediate Action List

21.4 The Open External Dependencies (Niki Watches, Captain Triggers)

These have lead times outside YBA Edge’s control. Captain fires them on Day 1 of the Matrix track. Niki watches and pings if blocked.

21.5 The Lock-In Reality

Per the locked plan:

• Total Captain time: ~10 days for EC Foothold + ~60 days for Matrix solo = ~70 days at >80% capacity
• Total cash spend on dev: R0 (Captain solo per Q28) — but trade-off: all other YBA strategic work pauses for ~10 weeks
• Founding-customer commitments: Matrix locked at R6,000/mo for life. EC farm pricing still TBD (was held in Round 1 Q9 — “discuss with her first”)
• Revenue runway: with Matrix + 2 more founding customers (R18,000 MRR + R15,000 onboarding banked), then standard ladder from customer #4, projected Year 1 top-line ~R1.07M
• The empire move: every line of code shipped to Matrix in packages/core/ and packages/med-engine/ becomes free YBA Med v1 code when the standalone product launches in 12-24 months. 70% reuse target.

Closing Note

This is the YBA Edge dental product plan. It’s been refined across 6 rounds of Captain decisions, 14 specialist agents dispatched, and one substantive Captain push-back (Q39 → Q47 — fix-and-improve over revert-and-refund) that fundamentally improved the framing.

The plan is now durable. Niki executes. Weekly progress digests will land in Captain’s Telegram. Any new decisions that emerge mid-build will use the same iterative-plan workflow (wiki/meta/iterative-plan-workflow.md) — but they’ll be operational tweaks, not strategic rewrites. The strategic plan is locked.

Captain — your move on EC farm signature is the single thing that unblocks the entire sequence. Once she signs, the wheel turns.

Run the rhythm, sell the output, the system runs you.

— Niki / YBA Edge Operations