Architecture & capability brief
A clinic sells time, delivers it, records it and gets paid for it. This page shows how the platform does each of those, what the pieces are and how they connect — and what that buys you commercially and operationally. Written for someone who has fifteen minutes, not a terminal.
People touch the top layer. Everything they do goes through a single gateway, which is the only thing holding secrets. The gateway asks the business core, which is where the rules and the records live. The core keeps its own data and reaches out to the outside world. Nothing skips a layer — which is why changing a payment provider or an AI vendor never reaches the app, and why the app can never reach the database.
/my — sessions, orders, invoices, chats, documents./my/expert — availability, sessions, reports, earnings./my/admin — the daily health dashboard and 17 reports.Each layer can be replaced without touching the ones above it. The payment provider is a setting, not a rewrite. The AI vendor is a setting. A second brand can run on the same core. And because the app never holds a secret and never sees the database, a lost phone is an inconvenience rather than an incident.
The most useful thing to understand about the architecture is one journey through it. Everything else on this page is a variation on these six steps.
A client taps a free slot. The app sends one authenticated request to the gateway and knows nothing else about the estate.
Token valid, rate limit clear, request well-formed. Anything malformed is refused here, before it reaches the business core.
Is that slot really free? Weekly hours, exceptions, existing bookings, room availability, notice period, booking horizon — all six must pass.
A session credit gets a time attached. The practitioner's share is calculated from the terms in force right now — and frozen.
One event fans out to push, email, in-app inbox and WhatsApp, on each person's own preferences and in their own language.
The order, the invoice, the practitioner's pipeline and the admin's reports all move together, because they read the same row.
Six availability tests run in the core, not in the app and not in a spreadsheet. That is why the platform does not double-book a room, does not sell a slot twice, and can answer "why can nobody book me today?" with a specific reason instead of a shrug.
A person is a client, a practitioner, an administrator — or all three at once. The platform gives them one login and shows the areas their role unlocks. That single decision removes a whole category of onboarding, password-reset and "which system was it in?" support cost.
Complete on its own — nobody needs the website to use the platform. Built once in Flutter, shipped to both stores, localised into 23 languages including right-to-left layouts.
The same data with room to breathe. Three portals off one sign-in, each showing only what that role is entitled to see.
The full business system underneath, for the work that is configuration rather than operation — and for finance, which belongs in a real accounting system.
The core is not one monolith. It is a set of modules that each own one part of the business, and depend on each other in a stated order. That is what lets a clinic switch on only what it needs — and what lets the same core serve a coaching practice, a clinic and a regulated health service without a fork.
Selling and delivering time
bookingCalendars, schedulers, rooms, locations and the availability engine.sale_meetingSessions sold as credits, cancellation ladders, package service agreements.clinic_platformThe platform layer: practitioner profiles, services, content, notifications.Getting paid, and paying out
expert_payEngagement terms as a dated contract history; payout runs built from sessions held.clinic_reportsThe seventeen alignment and performance reports.Accounting · Sales · HRStandard business applications, acting on the same customers and orders.The part that has to hold up
secure_document_base _cryptoEnvelope encryption, key custody, rotation and crypto-shredding. Eight modules.clinical_dms _eu _uk _usCare relationships, disclosure register and subject rights — with a pack per jurisdiction.session_reportsSession reports filed against the session, about the client, on the secure store.Signature and contract lifecycle
esign_base + 8 moreSelf-hosted electronic signature with a tamper-evident audit trail. No third-party signing vendor.contract_*Twenty-three modules: negotiation, approval, amendment, obligations, billing, legal reporting.Where AI is allowed to touch the business
ai_bridgeConnects the core to any LLM for prompt-driven analysis, tool calling and automated actions — provider-agnostic.Gateway AI serviceThe client-facing companion: streamed answers over WebSocket, never touching records directly.Who is who, and who may see what
user_extentionOne account carrying client, practitioner and administrator roles at once.Age & identity verificationAutomatic face check first, document review queue second, encrypted and auto-deleted after.This is the single most important diagram on the page. A service is sold, it becomes a credit, the credit becomes a booking, the booking becomes attendance, and attendance is what releases the money — to the business and to the practitioner. Break any link and the symptom shows up somewhere else entirely.
“A credit is what you own. A booking is when you spend it.”
Buying and booking are deliberately separate steps. That is what lets a client buy a package today and schedule the appointments over the following months — and it is why a cancelled session is not a lost one: cancelling detaches the time and hands the credit back.Reports, practitioner pay and earned revenue all wait on the session being closed as held or as a no-show. A session that was delivered but never closed is wrong everywhere at once — which is why stuck sessions is the report an administrator works first, every single day.
The practitioner's share is calculated from the terms in force at the moment of booking and fixed there. Change the terms next month and the work already done keeps its price. Every payout line records the contract version that priced it, so a question about a payment from eight months ago is answerable.
The cancellation policy decides what clients are charged, what practitioners are paid, how long credits live and how far ahead people can book. It is attached to products, so different services can behave differently — and changing it never reprices history.
Clinical and professional records are not ordinary rows in a table. They are held as secure documents, with five properties that hold regardless of who is asking — including the person who owns the company.
Every version has its own key under envelope encryption. Nobody reads records out of the database, and a database backup on its own is not a disclosure.
Access requires a rule that permits it. Being an administrator grants nothing by itself — access follows the client's care team, not the org chart. There is no general override.
Openings as well as changes, in a log nobody can edit or delete. If a client, a regulator or your own legal team asks who has seen a record, the list is complete.
A correction is filed as a new version; the original is never overwritten. An amendable record is worthless as evidence, and one day yours may need to be worth something.
When retention expires the key is destroyed rather than the row. The content is gone; the proof that it existed and was properly disposed of remains — which is what an auditor actually wants.
Clinical records ship with EU, UK and US packs on the same core — erasure and ROPA handling, withholding rules, disclosure registers — so one deployment can serve more than one legal regime.
An emergency access route exists for genuine urgency, and using it is a recorded event that is reviewed afterwards. That is the whole design in one sentence: access is available when someone truly needs it, and never quiet. It is a far easier thing to put in front of a data protection officer than a permissions matrix and a promise.
The same platform is sold three ways, because three different people sign. Below is what each of them gets, in the words they use themselves rather than ours.
Most clinic software books appointments and stops. This runs the whole chain — sells the time, delivers it, records it, pays the practitioner and proves what happened — so the clinic's numbers, its payroll and its compliance file are all reading the same row.
The platform is opinionated about management: it does not hand you a wall of charts. It hands you seventeen lists that should be empty, in an order, on a rhythm. An empty report is the good outcome — so the job is to find the lists that are not empty.
Eleven ask whether the record matches reality. Four compare how people are doing the work. Each is defined by what puts a row on the list, and each is meant to be worked until it is empty.
Worked until empty
Conduct, compliance and retention
Read with the fairness rules
Measured per opportunity, context always shown, rates under five sessions suppressed, what a person controls separated from what you control, every figure one click from the sessions behind it, and no league table on anyone's own page. A number nobody can defend is worse than no number.
The estate is four processes and a handful of contracted services. Every external dependency sits behind an interface with a mock on the other side of a switch — which is how the app can be demonstrated, tested and developed without a single live vendor account.
One compose file brings the whole stack up. There is no proprietary runtime and no per-core licence anywhere in that list.
Data, payments, AI and notifications each resolve to either a real provider or a mock, chosen by one setting. The consequences are commercial, not just technical:
All of them are in the gateway. The mobile app ships with public keys only; the browser gets signed, expiring URLs rather than credentials; the database is never reachable from a client.
Practically: an app can be decompiled and nothing is lost, and a rotated key takes effect for every user at once without an app release.
| Capability | Runs against | Falls back to | What breaks without it |
|---|---|---|---|
| Business data | odoo — JSON-RPC over a service account | mock | Everything. This is the system of record |
| Payments | stripe · paypal | mock, or manual transfer with uploaded proof | Card checkout. Orders still work through review-and-confirm |
| AI | openai · gemini | mock | The companion and AI analysis. Nothing clinical or financial |
| Push notifications | Firebase (FCM and APNS) | email, in-app inbox | Instant alerts. Reminders still reach people by email |
| SMTP | in-app inbox | Confirmations and invoices by mail | |
| WhatsApp Cloud API | push, email | One reminder channel among four | |
| Media & attachments | S3-compatible object storage | local storage | Uploads at scale. Records themselves are in the core |
| Voice & video | WebRTC, signalled by the gateway | chat, phone | In-app calls. On-site and phone sessions are unaffected |
No single external vendor can stop the clinic from selling, delivering and recording a session. That is the property worth protecting as the estate grows, and it is the reason each of these sits behind an interface rather than being called directly from the code that matters.
Two kinds of page follow this one. The blueprints take a single seat in the business and answer the same four questions — what they see, what they control, how it makes them faster, and what it does for the business. The guides then teach every screen, step by step, in nine languages.
Seven phases in swimlanes, all four viewpoints at once, and the fork between an online session and one on your premises.
The same business from the administrator's, the client's, the practitioner's and the accountant's chair.
The daily routine, all seventeen reports, policies, payouts, compliance and the back-office directory.
Availability, sessions, reports, clients, earnings, payouts and reputation — on the web and on a phone.
Finding a professional, buying, booking, attending, paying, and the records held about them.