Therapy practice management software for UK therapists
We were engaged to build Karu, a practice platform for UK therapists, with privacy built into its structure.
The market and the problem
Karu is a practice platform where privacy is structural, because clients hold no passwords, clinical notes never enter the search index, and every record carries its own audit trail. We designed and built it end to end for a family-run business, with a core build of about 14 weeks.
Most UK therapy happens in private practice, usually one practitioner working alone. UKCP's own member snapshot found 85 per cent in private practice and 70 per cent working mostly solo. These are clinicians first and administrators reluctantly, and the admin arrives between fifty-minute sessions.
In BACP's 2025 survey, 36 per cent of therapists described their practice as over capacity, running waiting lists or referring clients elsewhere. Hours spent on notes, scheduling and chasing payments are hours not spent on the waiting list.
And the data could hardly be more sensitive. Under UK GDPR, therapy information is special category data, and even a calendar entry showing that someone attends therapy qualifies. Yet much of the market runs on generic booking tools or platforms hosted a long way from the UK, with data residency mentioned nowhere on their pricing pages.
The brief: a practice system a solo therapist would enjoy using, with privacy built into its structure and the data held in the UK.
What we built
We built a platform that covers the rhythm of a practice: the diary, the session, the note, the follow-through and the money, in one interface.
Diary and scheduling for therapy practices
Weekly and fortnightly slots that run open-ended, edits scoped to this session, all future ones or the whole series, and proper handling of the awkward cases like months with no fifth Tuesday. Cancellations record whether they fell within policy, and non-attendance is a first-class state.
Structured clinical notes
SOAP, DAP, BIRP and GIRP formats as structured sections, with drafts that autosave locally and a finalise step that locks the record. A finalised note cannot be edited without a trace, which is how clinical records should behave.
Clients without accounts
Clients never get a login, because the safest credential is the one that doesn't exist. Session invites arrive by email with a calendar file, and video sessions are joined through a tokenised link that only works while the therapist has the room open.
Video built in
Sessions run on Karu's own video, with access tokens scoped to a single room and expiring with the session. Nobody needs a third account, and no meeting IDs float around inboxes.
The session companion
One panel beside the calendar holds notes, homework and the client's recent history, assembled by a single call. Homework between sessions (journaling, worksheets, exercises) is assigned and tracked, and whether it was done feeds into the next session.
Practice finances
Session fees, collected against expected, flags on unpaid sessions and a short-range forecast. Enough financial truth to run the practice, without pretending to be an accounts package.
The engineering
The interesting decisions on Karu were privacy decisions, and most of them were made before the first feature was built.
Karu in outline. The practice app uses the backend. PostgreSQL holds the true record, and the search index in Elasticsearch is a copy that can be rebuilt from it at any time. The platform is built for Google Cloud's London region, as the line under the drawing shows. Highlighted: the search copy, which keeps clinical note content out, so records are found by client, date and structure.
How recurring sessions are stored
A therapist can move a client's regular slot from next month on without disturbing a single past session. A recurring slot is stored once, as a template, and a session row is only written when something happens: attendance, a cancellation, a note. A weekly client for five years costs one row until real life intervenes, and series edits stay simple because the past is fixed fact and the template governs the future.
Data kept separate by practice
A forgotten filter cannot expose one practice's records to another, because nobody has to remember the filter. Every database statement and every search filters on practice and user before any other condition, taken from the sign-in token rather than from anything the browser sends. Each kind of ID is a separate type in the code, so passing the wrong ID to the wrong place fails to compile.
The card "How recurring sessions are stored", drawn. A recurring slot is stored once, as a template, and a session row is only written when something happens: attendance, a cancellation, a note. Highlighted: the session row, written only when something happens.
Can search reveal what was said in a session?
No. Clinical note content is deliberately kept out of the search index, so records are found by client, date and structure, never by what was said in the room. Search convenience is not worth an index full of disclosures.
Client access and video links
Clients have no password to lose or have phished, because they never get an account. A video join link is checked three ways before a room opens, and access to the room ends with the session. Appointment status changes follow fixed rules, and appointments can be cancelled but never deleted.
UK hosting and a rebuildable search index
Client data is built to stay in the UK, and rebuilding search never takes the platform offline. Everything is built for Google Cloud's London region. PostgreSQL holds the true record and the search index is a copy that can be rebuilt from it at any time; the rebuild checks its counts and rolls itself back on a mismatch. Notifications are self-hosted, behind a proxy that can only reach approved addresses.
Where AI fits
Therapy tech is rushing into AI, and the profession is rightly wary: BACP guidance is blunt that real session details must never be pasted into general AI tools, and NHS guidance treats AI summarisation of clinical content as likely a medical device. So we did the unfashionable thing: we designed for AI and have not shipped it yet.
Karu's AI drafting as designed, not yet shipped. A model could only ever write to an unfinalised draft, and a clinician signs every record before the note is locked. Highlighted: the draft.
- Iron mark: a clinician signs every record.
Notes structured for AI drafting
Clinical notes are stored as structured sections for each format, precisely so a drafting model could propose content section by section. The finalise-and-lock flow would then be the safety mechanism: AI could only ever write to an unfinalised draft, and a clinician signs every record.
Attendance risk scored in the platform
The platform already holds attendance history, cancellation patterns, session cadence and homework completion. Non-attendance risk can be scored in-process on that data, with nothing sent to a third party, and surfaced as a scheduling nudge rather than a label on a person.
Intake triage as ranked suggestions
Structuring a presenting-issue note into suggested session type and urgency helps a practice route its waiting list. UK GDPR has firm views on automated decisions about people, so the design is ranked suggestions a human accepts or overrides, with the override recorded.
Rules for AI on client data
Any inference over client data means UK or EU residency, a contractual bar on training with customer data, a data protection impact assessment first, and features that ship off by default. Only about one in nine practitioners uses AI at all, so nobody loses a race by getting the safeguards right first. The same rules are where we start when we advise a company on AI governance.
Phases, team and price
Delivery record
- Status
- In build
- Discovery
- 2 weeks, including the privacy design
- Core build
- About 14 weeks
- Team
- Senior engineers
- Hosting
- Built for Google Cloud, London region
Case study published , updated .
The Karu engagement is a focused build, with the privacy work done at the start, before any feature was built. Of the platforms we price in public, this shape is the smallest; a single-workflow MVP costs less again.
Four phases, in the order listed below. Highlighted: phase 2, core build, which reached a working practice system.
Indicative price
£90k to £140k for this phase
A privacy-first practice platform at this scope, scheduling, records, notes and video with a small senior team, typically runs £90,000 to £140,000. Deeper regulated builds with wider compliance scope tend towards £155,000 to £210,000. Excludes third-party costs, at London rates as of mid-2026. Bands for the shape, not an invoice.
The bands in this study's price note, on one linear scale from zero and numbered in the key. Each is a band for the shape, not an invoice. Highlighted: band 1, the one this page leads with.
- 1. Scheduling, records, notes and video: £90,000 to £140,000
- 2. Deeper regulated builds with wider compliance scope: £155,000 to £210,000
How we build
What every build goes through
These commitments hold on every build we run:
- Nothing is built until the specification is written down and you have agreed it.
- A senior engineer reviews every change before it is merged.
- Automated tests run on every change, and a failing build does not ship.
The delivery record shows this project's own details. How we work sets out the rest of the method.
What the engagement achieved
Karu reached a working practice system after a core build of about 14 weeks. The part we would show a technical due diligence reviewer is the privacy work: every query walled off by practice, clinical content kept out of the search index, and no client credentials to steal.
Because of how the notes are stored, the AI phase can arrive as a switched-off feature, with no rebuild.
- Every query filtered by practice and user, enforced in the code's structure
- Clients hold no credentials, and each video link works only for its own session
- Clinical notes excluded from search indexing by design
- Built for UK data residency on Google Cloud's London region
What Karu's outcome says about its structure: every query filtered by practice and user, clients holding no credentials, clinical notes excluded from search indexing, and a build for UK data residency. Highlighted: privacy, which the summary says is structural.
The decision we would defend
Clinical notes never enter the search index
Records are found by client, date and structure, never by what was said in the room. Some searches are less convenient as a result. We would make the same call again, because search convenience is not worth an index full of disclosures.
Planning something like this?
Indicative price
£90k to £140k for this phase
A band for the shape, not an invoice.
The first step
Specification sprint
£4,500 or £8,500One to two weeks
The written specification, architecture, estimate and risks: one week for a single workflow, two for a platform. You can take it to any supplier, us included.
Asked about this project
What is Karu?
Karu is a practice-management platform for UK therapists and small practices: session scheduling, structured clinical notes, client records, built-in video and a practice money view, designed privacy-first and built for UK hosting. It is in build. Quantum Craft was engaged by a family-run business to design and build it end to end.
What makes Karu privacy-first?
The way it is built: clients hold no login credentials, clinical notes are excluded from search indexes, every query is walled off by practice in the code itself, records are append-only and finalised notes are locked, and the data is built to stay in Google Cloud's London region.
Does Karu use AI?
Not yet, deliberately. The notes are structured so an AI drafting layer can be added with a clinician review gate, and the design rules for it are set: UK or EU inference only, no training on customer data, a DPIA first, off by default. In this sector, doing AI credibly matters more than doing it first.
1 more question
What does a platform like Karu cost to build?
A platform of this shape, with scheduling, records, notes and video built by a small senior team over about 14 weeks of core build, usually runs £90,000 to £140,000. Wider compliance scope, more integrations or a larger team moves a build into the £155,000 to £210,000 band. A single-workflow product built to production standard typically costs £35,000 to £80,000 over 6 to 12 weeks.
Tell us what you're building or deciding.
Tell us about a product you want built, or a decision about AI you need to make, and we'll set up a 30-minute call. You'll get a straight answer on what it would take.
What happens after you get in touch
We reply within one working day
By email, to arrange a time for the call.
A free 30-minute call
With a senior engineer, about what you are building or deciding.
The fee in writing first
If a first step is worth taking, you get its exact fee in writing before any work starts.