Nothing new built — this is what already exists. Every number was read directly out of our own systems on 27 July 2026: the ClickUp board, the App Everything Doc, and our FY26 headcount file. Three corrections to the brief you read are flagged where they arise.
← The original strategy brief, if you need it againI found this while pulling your answers together. It is on production now.
The row-level-security policy on public.users has no column restriction and no WITH CHECK. Any authenticated user can PATCH their own record and set is_premium: true, bypassing every paywall in the product — or set user_type: "admin", which grants app-wide administrative access across every admin policy, including the records of all 650 members.
It is pre-existing and app-wide, not introduced by recent work. Mo found it himself during self-review, wrote it up accurately and proposed a correct three-step fix. It isn't a one-line change, because the current purchase flow sets is_premium from the client.
I'm not raising it for drama. An urgent, correctly-diagnosed, business-critical defect that nobody has been assigned to for five days is the ownership problem expressed in a single ticket — and it is probably the most useful evidence I can give you for the read you offered.
I nearly sent you only half of this. Mo plans in a Google Sheet — the "App Everything Doc" — and the team executes in ClickUp. Both are live: the sheet was last touched 22 July, the board daily. Neither on its own tells you what is shipping this week, and they disagree with each other. You should see both.
A proper roadmap, and better structured than I expected: user type, feature, rationale, deployment date, build hours, priority, named developer, links to Figma prototypes and engineering blueprints. Roughly 45 features from March 2026 out to November 2026.
Two things in it matter more than the rest. First, the status columns hold due dates rather than statuses — "Due Live 30 Apr", "Due Live 30 May" — and they were never updated as those dates passed. Second, look at what is ranked. Every forward-looking item from August to November is priority Low. The only items marked High or Urgent are ones whose dates have already gone by — the legacy database migration was Urgent and due 30 April; live virtual events were High and due 30 April, now showing July.
So the roadmap does not contradict what I told you. It says the same thing in a different hand: nothing forward-looking is ranked above Low, and the ranked things are late.
This is where the work actually moves: one list, ProF App, ten-stage workflow, updated daily. Counted directly on 27 July —
44 items have working code written. Two have been merged. Nothing at all is on staging.
This does not look like a team that struggles to write software. It looks like a team whose finished work pools at review-and-merge and never reaches production. That would also explain what I described to you as iterations making things worse — the longer completed branches sit unmerged, the more they drift from main and from each other, so merging one thing breaks another. Total work in progress is 66 items against a queue of more than 400.
Almost every one of the 400+ is priority "normal" or unset. With nothing ranked, priority defaults to whoever asked most recently.
Live bugs, implementation sub-steps ("Task 1: DB migration", "Task 2: edge function") and whole unstarted feature sets are all filed together.
Health Passport and the Flora AI coach sit in open PRs. Roughly two fifths of all work in progress serves an audience with zero users — and it isn't merged.
I told you the patient side was unbuilt. That was wrong. Health Passport and the Flora AI coach have working code sitting in open, unmerged pull requests — around 25 tasks. Arguably a worse position than unstarted, and I'd rather correct it than have you find it.
We planned to move 750 paying members onto the app in March. By 15 April, 50 had moved.
It is written in the sheet, in our own hand, as a note against the launch timeline: "15 APR — only 50 users moved to app". I don't believe it was ever treated as the emergency it was. It is the same adoption problem I described to you as 650 members and 100 weekly actives — visible early, recorded honestly, and nothing in the roadmap sequence changed in response to it.
The second: the sheet carries a financial model projecting 11,894 paying members and £1.15m of monthly revenue by month 12, on £36k a month of ad spend and 15% monthly churn. We are at 650 members. I am not troubled by a model being wrong — they always are — but nobody appears to have gone back and reconciled the plan to the outcome, and the roadmap is still sequenced as though the model were true. That may be the most useful single fact I can give you about how we operate.
The company rhythm is well defined. The engineering rhythm inside it is much less so, and I think that gap is the honest answer.
The board already models a proper flow — review, merge, stage, production. The stages exist and simply aren't being moved through.
Which suggests the fix is a cadence and an owner rather than a new process or a new tool. Caveat: this is what our systems record. Mo should confirm what actually happens each week, because the two aren't always the same.
No system or data-flow diagram exists. But my first answer — "we have nothing" — was wrong, and the truth is more useful to you.
Inside the same Everything Doc there is a full tooling and compliance table — hosting, database, backend, AI, auth, notifications, video, wearables, analytics, payments, security — each with a recommended tool and HIPAA/GDPR notes. And a 14-entity data model: User, Profile, Protocol, Comment, ScienceArticle, HealthPassport, WearableData, Subscription, AIConversation, Folder, Consultation, ShopOrder, Notification, Referral, with attributes, types and relationships.
That is closer to an architecture document than I credited. It is also, on the evidence, a design from early 2025 that was never reconciled with what got built.
The design doc specifies MongoDB and Python/FastAPI. The system that exists runs on Supabase and Postgres.
My brief repeated the doc, which is where I got it wrong. Every piece of evidence on the live board says Postgres — edge functions, pg_cron, row-level security, SQL migrations. The doc's own documentation column even links to Supabase docs while the tooling column recommends FastAPI, so the drift may have started early. Around it: Flutter for mobile and web view, Stripe, Firebase Cloud Messaging and APNS, BigQuery for reporting, PostHog for analytics.
The practical consequence: the only written data model we have is MongoDB-shaped and describes a database we don't run. If you were to reason from it you would reason about the wrong system. Mo should confirm, but I would treat the doc as historical.
The three-surface problem is not static — migration off WordPress and GoHighLevel into the app is an active workstream, largely owned by Vaclav. Content, subscriptions and media are being moved. So the honest framing is "mid-migration, taking a long time" rather than "three surfaces and no plan".
One more artefact you may want to ignore: the sheet also holds an MVP task list, T1 to T15 — infrastructure, auth, profiles, protocols — with every row still marked "Not Started", even though the app has been live since March and most of those things demonstrably exist. It is abandoned rather than accurate, and it is a fair illustration of the wider point: we create planning artefacts and then stop maintaining them.
From our FY26 headcount forecast. Actuals run to April 2026; from May onwards these are forecast figures, so treat them as the shape rather than this month's invoice.
| Person | Title on the books | Engagement | £ / month |
|---|---|---|---|
| Rob Tribiana | Full Stack Developer | Contractor | 2,857 |
| Bruno Giacomet | Technical Product Owner | Contractor · end date "Speak to MR" | 2,256 |
| Vaclav Skarka | "3rd Party App Tester" | Via Health3 AG · end "Speak to MR" | 2,195 |
| Rose Lim Honglay | Project Manager | Contractor | 1,570 |
| Dalia Raafat | Full Stack Developer | Contractor | 566 |
| Kateryna Zashalovska | Mobile App Development | Contractor · end "Speak to MR" | 50 → nil |
| Everyone building the product | All contractors | ≈ 9,500 |
Mo is the only employed person here — about £10k a month all in, split between technology and growth. We don't record the ratio.
Contractors alone — everyone who writes or ships code or design.
Contractors plus half of Mo, our best guess at his technology share.
Everything, with all of Mo allocated to the app.
Roughly £115k–£235k a year for the entire product function. Total company payroll for context is about £90.7k a month.
A full-time CTO at market is around £12–16k a month loaded. That isn't an addition to what we spend on product — it's close to a doubling.
It would also make that person the largest single line in the function, sitting above a build team that amounts to perhaps two people's worth of time. Which is why I'd rather have your view on shape than on salary: "hire senior leadership" and "make the people we already have actually present" are competing uses of roughly the same money.
You were right to ask this one, and I hadn't seen it clearly until I went and checked.
Mo is the only employed person. Everyone else building the app is a contractor.
Three of those contracts — Bruno, Vaclav and Kateryna — have their end date recorded in our own finance file as "Speak to MR". Vaclav is contracted through a company, Health3 AG, so he is almost certainly serving other clients.
Named, active, holding assigned work on the board.
What those six plausibly amount to, inferred from what we pay them.
Dalia is on £566 a month.
She owns the push-notification system, the web-view Rock, gamification, the BigQuery scorecard and a large part of the patient-app build. At any plausible rate that is four to six hours a week. Rose at £1,570 and Rob at £2,857 are clearly part-time too. What I cannot tell you is what share of anyone's week we actually get versus their other clients — we have never recorded it. Mo would have to answer that.
Less about salary, more about shape. Given the numbers above, hiring a senior technical leader and making the people we already have actually present are competing uses of roughly the same money.
I don't know which comes first. You'll have seen both go wrong. Whenever suits you for the call — I'll have Mo on it if that's useful.