Life-Therapy

The situation

A South African online counselling and coaching practice, running on paper.

Bookings were arranged by message and written down. Sessions were reconciled by hand. Invoices were raised after the fact, and the practice found out about a lapsed credit or an unpaid account late, when someone went looking. None of that was a failure of care — it is what a small practice looks like when the administration grows faster than the time available to do it.

The constraint that mattered was the practitioner's attention. Every hour spent reconciling was an hour not spent with a client, and the practice could not grow past the point where the paperwork consumed the day.

The practice is my wife's. I built it through Yoros as sole technical owner: greenfield architecture, production launch, and the stabilisation afterwards.

What I did

I built the practice a platform rather than a website — admin portal, client management and bookings on Next.js and Prisma, with the administration designed out rather than digitised.

The scheduling problem was the first one worth solving properly. Bookings sync two ways with Outlook through Microsoft Graph, and every booking creates its Teams meeting automatically, so a session exists in one place and the link is never chased.

Communications run on the Meta WhatsApp Cloud API across eight approved templates — session reminders, the billing lifecycle, credit-expiry warnings. WhatsApp is where South African clients actually are, which made approval and template discipline worth the effort. Numbers are normalised to E.164 on the way in, and the scheduled sends are idempotent, because a reminder system that double-sends under retry teaches people to ignore it.

Billing runs end to end: pro-forma invoice, payment, webhook confirmation, then the tax invoice raised automatically. Video and PDF material is delivered through a CDN rather than from the application.

The stack is not the point and does not belong in the practice's shop window. It is here because it is checkable.

What changed

The practice runs on a system instead of on memory. Bookings, reminders, payments and invoices happen without anyone shepherding them, and the credit and billing states the practice used to discover late are now surfaced by the platform rather than found by looking.

What that buys is the practitioner's attention back — the constraint the whole build was aimed at.

It went to production and has been through post-launch stabilisation, which is the part of a build that decides whether it is genuinely in service or merely delivered.

What I'd do differently

I built it with the practitioner rather than for her, which was right. What I got wrong was how I asked for feedback.

She is expert at the work the platform supports and not a technical person, and I treated her as a tester without ever explaining what testing meant. "Does this work?" is not a question a non-technical person can answer usefully — it invites a yes, particularly from someone who does not want to be discouraging about something you have built for them.

So we launched things I thought were finished, and the flaws surfaced later: a client doing something the flow did not expect, or an automated sequence failing at month-end when the billing cycle ran for the first time under real conditions.

That is my failure, not hers. If I ran it again I would give the domain expert a script — specific tasks to attempt, permission to break it, and an explicit brief that finding problems is the job and finding none is the bad outcome. And I would run a full month-end against real data before calling anything live.