We train the clinicians who run private health and aesthetic clinics. Now we're building the platform where they and their patients run health protocols together — skin, weight, hormones, sleep, longevity. This document is the opportunity and the obstacles, told honestly.
Most technology companies spend years and millions manufacturing the two things that can't be bought: an audience that actually listens, and a professional network that trusts you with their reputation. We already have both. What we don't have is software that turns them into a compounding machine.
They pay us monthly for access to the app. That is the entire business model on the platform today. Around 100 of them opened it in the last week — a number we will not hide from, because it is the most useful thing we can tell you.
We do not have a single patient using the platform. Everything patient-facing in this document is a design and a strategy — not a deployment. We are not going to pretend otherwise.
Patients will get their own tiers running in parallel with the clinician's — almost certainly much cheaper, probably several of them. None of it is priced, built or tested yet.
550 clinicians pay us every month and did not open the app last week.
We are not hiding this and we are not apologising for it — it is the clearest evidence we have that the strategy in this document is the right one. A library of courses does not create a habit. 650 people bought the content; 100 have a reason to come back. Every module in the next section exists to change that one number, and it is the number we would judge a first year of work on.
Years of teaching have built genuine reach among practising clinicians — the exact people whose businesses we now want to run software for. Distribution is solved.
In a field where a bad decision can blind a patient, clinicians follow the person they believe keeps them safe. That trust transfers to what we build.
Every marketplace dies of cold-start. We already own the hardest half of ours: trained, certified, real clinics — before a single patient arrives.
The prize isn't a better course player. It's becoming the operating system of an entire profession — and the layer that connects it to the patients it exists to treat.
Six people work on the app. Job titles are not formally defined here, so what follows is what each person actually holds — taken from the work assigned to them, not from an org chart.
Holds backend architecture for the Confidence Engine, the full written specification for the patient app, and the technical direction of the team. Also carries a substantial commercial and operational remit — covered in detail below.
Owns infrastructure and migration: moving LearnDash and GoHighLevel content, subscriptions and media into the app; Supabase backend; SQL performance; security hardening; CI build-health checks; and the PostHog analytics setup.
Built the push-notification system end to end (FCM, APNS, web push, queue and batching). Admin panel, Flutter and web-view development, database migrations, bug fixing. Also maintains the BigQuery scorecard and membership numbers.
Feed, community and commerce: feed media and search, polls, notifications, account deletion with row-level security, subscription products and Stripe. Also handles PR review and stage/production deployment.
Figma design, prototypes, UX and the design system — plus iOS and Android store releases and keystore management, and writing user stories, acceptance criteria and MVP scope. Three functions in one person.
Dev/stage/production validation, production support, incoming bug triage, scoping and effort-estimating features from designs, validating designs against business requirements, and coordinating beta testing.
Mo did not arrive as a technology leader. He joined Profinity as our growth marketer.
He became genuinely interested in technology, wanted to build and lead a technical team, and has done exactly that. The six people above largely exist as a team because of him, and he now holds both the architecture and the delivery of the product.
He is also still carrying the commercial side he came from: supplier invoices, software licences, board agendas, FY26 sales and gross-margin targets, cash-burn reporting, lifetime-value modelling, recruitment, and GDPR and DPIA compliance. One of his current quarterly objectives is revenue of £1.65m and £75k profit. That is a technology leadership role and a commercial leadership role held by one person at the same time.
The open question this document exists to help answer: whether the technical role Mo has grown into should, at the next stage of the company, be held by someone with deeper platform experience — and if so, what that means for a person who would be very difficult to replace on everything else he does.
Each move only works if the one before it is real. Read them as a sequence, not a menu.
The clinician is who pays us today, and the long-term strategy on their side is simple to state and hard to build: the more of their business runs through our app, the better the service they get — and the less thinkable it becomes to leave. Not lock-in through contracts. Dependency through genuine usefulness.
Here is the full surface we intend to own. Note the status flags. One of these is live.
Revenue, margin, chair occupancy, average spend, retention — read back to them plainly, with the one number currently limiting the business flagged. Most clinic owners genuinely do not know which lever is stuck.
Demand routed into their actual diary. This is the promise with the highest pull and the highest risk — it is instantly visible when it under-delivers, which is exactly why it has to be proven in one city before it is sold anywhere.
The clinician runs their own recurring patient membership, hosted on our platform, under their brand. Their patients become members — of theirs, on our rails. This is the piece that changes the shape of the whole company, and it is covered properly at the end of this document.
Treatment packages and courses of care sold through the app, with redemption, expiry and outstanding liability tracked. Today most clinics run this on paper, memory and goodwill — and lose money on all three.
Course delivery, the community feed and the membership subscription all work now. The community is comfortably the most engaging thing we have — which is a strong hint about what actually earns a daily habit.
Sitting over the modules above: diagnose the single constraint in the business, sequence what to do about it, check whether it moved. Useless without the data the other modules produce — which is precisely why the order of the build matters.
A clinician who runs their money, their diary, their membership and their packages on our platform does not churn. Content does not retain anybody. Being the system their business runs on does.
This is the part to understand before anything else. We are not building a skin app, and we are not building an aesthetics app. We are building the architecture that lets a patient and a clinician run a health protocol together — the patient doing most of the work themselves in the app, the clinician stepping in for the parts that require a clinician.
Weight loss. Hormone optimisation. Sleep. Energy. Skin. Longevity. Each of these is the same shape of problem, and each resolves into a sequenced plan across the eight arms of the Profinity Spiral. The engine doesn't change between them. It just re-weights the arms around whatever this person is optimising for. Pick a goal and watch the same architecture re-aim:
650 paying members, ~100 weekly active. Learning, community and billing work. The business modules do not exist yet.
Not one patient. No assessment, no protocol engine, no patient app. Everything shown is design.
Patient plans will run alongside the clinician membership at much lower price points — several tiers, none of them decided.
Every diagram from here to the end of this document responds to that choice. That is the point being made: new goals are new data, not new apps.
Each intervention carries mechanism, timeline, evidence strength, cost, ease and impact priors, tracking measures and safety gates. Authoring a new goal means writing rows, not shipping an app.
Every intervention is re-scored for ease against this person's actual life and impact against their actual constraint. Priority is computed, not authored — which is what makes it feel like it was written for them.
Whichever goal someone picks, the plan reaches a step only a clinician can perform. That is not a bolt-on business model — it is structurally where every protocol leads.
Build the architecture domain-agnostic. Launch it one domain at a time. And stay in non-medical optimisation — skin, body composition, sleep — for as long as the market allows, before entering regulated ground on purpose rather than by accident.
The subtlety a technical partner needs to hear from us rather than discover later: the subject matter is not what triggers regulation — individualisation is. An engine that tells a named person "your constraint is X, here are your steps" is making an individual recommendation whether the topic is skin or hormones. We expect to become a regulated medical device in time. That means building device-ready from the start — versioned content with approval workflow, traceability of which protocol version each person received, sign-off records, adverse-event capture. Cheap in the schema today; a rebuild if we leave it.
This is the insight the whole build rests on, and the fastest way to see it is to put the machinery down the middle. The gold column never changes — not when you swap the audience, and not when you swap the health goal. Only the content either side of it does.
Changing the goal rewrites the right-hand column only. The engine and the clinician's side are untouched.
"Fill your diary without discounting"
A free asset that promises one specific outcome
Pricing, pipeline, retention, capacity, hours
Structured intake that resolves to a machine-readable state
The honest answer they can't see from inside
The engine names the single binding constraint. One, not a list.
Ordered, gated, dependent on their state
Generate an ordered protocol of steps against that constraint
Do the offer. Post the case. Call the lapsed list.
Steps land as tasks, prompts and reminders — the efficiency gain
The step that needs another human
The step software can't do — and where the money is
Evidence the constraint moved
Evidence updates the state. The next constraint surfaces.
Note step 6. The patient's protocol contains an in-clinic step, so the patient product is the advertisement that fills a member's chair. The two instances pay for each other.
Here is what that means in product terms. Two audiences, two vocabularies, one component library — the cards don't move, they only change what they say. Hover or tap any card and its twin lights up on the other side.
Switch goal and watch the right-hand phone. Same six components, same layout, same code — different protocol.
A protocol is a plan, and plans do not open themselves. The thing that turns a protocol into a habit is not the protocol — it is a feed of content that keeps pulling people back to the next action in it. Three surfaces, one loop, and the loop is the product.
Not generic industry news, and not an algorithm chasing time-on-app. The things this person needs to know in order to reach the goal they are actually working on — which the platform already knows, because it wrote their protocol.
The same surface, named for who you are:
The step is done, the state updates, and the next thing they see is chosen against where they now are. The loop closes and starts again — which is the difference between a content library and a habit.
Every other feed is optimised for attention. Ours is optimised for the next action in a plan someone has already committed to.
The news feed exists, and it is the piece we most need a better answer for.
It is not intuitive to use. The structure is not right. And the clearest symptom is that people do not post as often as they should — which for a feed is close to fatal, because a feed nobody contributes to is just a newsletter with extra steps. It is also, today, completely disconnected from any protocol, because no protocols exist yet. So it is generic content in a structure people do not enjoy.
Contribution is the fuel. If sharing a case, a result or a question is not the lowest-friction action on the screen, the feed dies and takes the community with it.
Not from engagement optimisation. What someone sees should be governed by the step they are on — which is a ranking problem with an honest signal, and a genuinely interesting one to solve.
Feed → the action it inspired, without navigating. If reading something good and acting on it are two separate journeys, the loop leaks at exactly the point it was supposed to close.
Build a protocol once and it becomes four things at the same time. This is what makes the roadmap tractable instead of infinite — every feature either creates protocols, delivers protocols, certifies people to run protocols, or fills them.
"Your researched plan to the result you want." A consumer product, and the lead magnet that starts the relationship.
"What you are certified and equipped to deliver." Training, certification, and a reason to stay current with us.
The journey it runs: assess → plan → home steps → clinic steps → monitor → next. This is the core product loop.
Patient subscription, product sales, and the clinic's recurring demand fee. One object, three revenue lines.
If these were genuinely different products, this would be several systems. It isn't one system per audience, and it isn't one system per health goal. Here is the whole loop as data — the only thing separating a clinic-building protocol from a weight protocol from a hormone protocol is a discriminator field and the content authored against it.
role clinician|patient
locale
state jsonb
profile_id
schema_id
answers jsonb
assessment_id
binding enum
confidence
domain enum
targets constraint
version
protocol_id
order · gate
venue self|clinic
step_id
completed_at
evidence
profile_id
measure · value
observed_at
Two roles, many health domains. One engine, one deploy pipeline, one team. Get this right and every protocol after the first costs a fraction of the first.
A two-sided system is normally a curse — you need both sides before either works. We are starting with the expensive side already built.
Training clinicians is profitable today. It produces trained, certified practitioners — the inventory every health marketplace spends years and millions trying to assemble.
Because the network already exists, a patient's protocol can end in a real appointment with a real certified clinician from day one. No cold start on the hard side. None of this side is built — the engine is a plan, not a product.
A full diary is the single strongest reason a clinician never cancels. "Stay in the membership and we keep your chair full" beats any amount of content. Demand is the retention mechanic the education business has never had.
Every protocol run across the network produces outcome evidence nobody else in this field holds. Better evidence → better protocols → better results → more patients → more members.
The strategy is not "do all of this." Every phase has a gate, and advancing before the gate is met is precisely how we lose months. Holding this line is arguably the job we're hiring for.
Lock the legal shape of the money. Know the patient as well as we know the clinician.Where we are
Legal green-light, and a patient profile as rich as our clinician one.
One city. One protocol domain — skin first, because the authority and the content already exist. Our own clinic as the ring-fenced lab. The entire funnel instrumented: spend → lead → booked → showed → treated → value.
A profitable closed loop we can see end to end.
Directory, recurring demand subscription, certification. Saturate a city's supply before scaling demand.
Members asking for more volume, at a fee with real margin.
Weight, hormones, sleep, longevity — each one is new authored data on an engine that already works. Chosen by demand × supply-readiness; never ship a protocol no member can deliver.
The network can actually deliver it, today.
Roll the proven city playbook outward.
Per-city unit economics proven, not assumed.
UK law forbids advertising prescription-only medicines to the public. The patient-facing product leads with an outcome and an assessment — never the drug.
Clinical fee-splitting is a regulatory landmine. Money from a clinic must be a fixed marketing fee, never a share of clinical revenue. This shapes the data model, not just the copy.
If the app captures real outcomes across a whole network of clinics, we own something nobody else in this field has: proof. Better proof → better protocols → more patients → more members.
No gloss. This is the honest state of the platform as we understand it today.
We're putting this in the document rather than saving it for month two, because the person we want is the one who reads this list and gets interested rather than nervous. The engineers are not the problem. Bugs get reported and they get fixed. The problem is the rate of real improvement.
Things get built in an order that doesn't compound. A feature lands, and it isn't obvious how it advanced the phase we're supposedly in.
Scope runs from core membership out to speculative features, with nearly everything marked low priority. When nothing is forced to the front, priority defaults to whoever asked most recently.
Architecture and sequencing are spread across contractors and an internal lead. No single person's job is to say: this, then this, and not that yet.
Work dated for one month deploys two or three months later — and the slip is discovered after the fact rather than forecast before it.
A fix in one place surfaces as breakage in another. "Make mobile match web" has been open for months. Rework is eating the capacity that should be buying progress.
Courses, then membership, then demand network, then the protocol model. Each shift was right — but no team can sequence against a moving target, and some of the disorder downstream is honest confusion about which version is being built.
The failure is at director level, not developer level. The coders are working on the wrong thing at the wrong time — and even when execution is good, it doesn't tie back to the strategy in the right order.
We'd rather be told than guess. Here are the four candidates, with the honest case for and against each — our own reasoning, laid out so it can be argued with rather than agreed to. If you think we've weighted these wrong, that is exactly the thing worth an hour of your time.
If you take one idea away from this document, take this one. We call it the synergistic parallel community — or, more precisely, a recursive linchpin model. We run two memberships side by side, and each one makes the other harder to leave.
We are the linchpin for the clinician: the system their business runs on. The clinician is the linchpin for their patient: the person they trust with their face, their weight, their health. And the patient is a member of Profinity in their own right — introduced by their clinic, cared for by their clinic, but with their own account, their own record and their own subscription. Two parallel communities, one platform, deliberately linked.
That last point is a deliberate decision, not an accident of architecture. If a patient's clinic doesn't offer everything that patient needs, we can still help them — and if a patient moves, changes city or changes clinic, their protocol and their history come with them. It only works because the relationship is theirs, not rented from someone else.
Monthly and recurring, for access to the app. 650 members, roughly 100 active in the last week. This is the only revenue on the platform right now, and it funds everything else here.
Not out of goodwill. Recurring revenue share on that patient's subscription, an attribution lock so their patient is never routed elsewhere, and the plainly commercial reason: a patient running a protocol books more, complies more and stays longer.
Their own account, their own record, their own subscription — at a much lower price point than the clinician's. Introduced by their clinic and cared for by their clinic, but not owned by it. If they move city or change clinic, their protocol and history travel with them.
A patient mid-protocol does not drift away from their clinic. A clinic whose patients are engaged, booked and visibly progressing does not leave the platform that produced it. Retention rises on both sides at once — which is the entire reason to build it in this shape.
Most platforms fight to retain their users. We intend to retain our users by helping them retain theirs.
The two hardest problems in this business solve each other. The cold-start problem on the patient side is solved by the clinicians we already have; the retention problem on the clinician side is solved by the patients they already have. Every clinician who brings their list brings users we never had to buy — which is why the patient side does not need a consumer advertising budget to begin.
And the honest risk, stated before anyone else says it: the moment a clinician suspects we are collecting their patients rather than serving them, the B2B relationship that pays all the bills is poisoned. The non-poaching commitment has to be contractual, visible and expensive for us to break — and the revenue share has to be real. This is built for the clinic's success or it does not get built.
This isn't a pitch and there's nothing being sold. We've written it all down — including the parts that don't flatter us — because an hour with someone who has actually run this is worth more than another quarter of us guessing. These are the questions we'd most value your view on.
We think the failure is at director level, not developer level — nobody owning the order of work. Is that what you'd see, or is it something else? Where have you watched this before, and what did it turn out to be?
Four people, three surfaces, 650 members and 100 of them active. With those constraints and no new money — what's the first move, and what would you deliberately leave broken for now?
A CTO, a product lead, a designer, fractional or full-time — what does good look like at our size, what does it cost, and what would you check before believing anyone's claim to be it?
There is a version of this company where every private clinician in the country runs their practice on our software, and every patient runs their health protocol through it. The gap isn't the idea. It's everything between the idea and shipping it well.