The intelligent front desk for aesthetic clinics

How to read this document

This is the complete working record of IRIS – what it is, who buys it, what they pay, what it costs to build and run, when it makes money, and what could go wrong. It is deliberately not a pitch deck.

A deck asks you to trust whoever wrote it. Every number has already been reduced to a headline, and the assumptions behind it are gone. This document keeps the assumptions visible so that you can disagree with them. If a figure looks wrong, the working is here to check.

You are not expected to have any background in software, artificial intelligence or South African privacy law. Everything technical is explained where it first appears, and Appendix F is a plain-English glossary of every term used.

What each part is for

Three things to know before you start

1. Nothing is built yet. This is a plan with a costed, sequenced first step, not a product being sold. Where the document describes what IRIS does, read it as what IRIS is designed to do.

2. Every figure is indicative and based on averages. Supplier rates, market prices and assumptions all move. Each figure should be replaced with a written quotation or an actual invoice before it is relied on. Where a range is given, the low and high are both plausible.

3. IRIS is deliberately narrow. It does one part of a clinic’s operation – the front desk and the patient relationship – and refuses several adjacent, obvious-looking opportunities. Appendix B lists what it will not do and why. That discipline is what keeps the build affordable and the regulatory exposure manageable.

If you only read the money

The section below summarises the commercial picture. The detail behind it is in Appendix A (what it costs to build), Appendix D (what cash is needed and when) and Appendix E (every running cost, and the break-even arithmetic).

Appendix H sets out the questions worth putting to PulseHealth before committing to anything. They are the questions that would be asked of any software venture at this stage, and they are included because informed scrutiny is more useful than polite agreement.

The commercial picture in one page

Every figure below is explained in full later in the document. Section and appendix references are given so that you can go straight to the working.

What is sold, and to whom

Revenue per clinic

Cost per clinic

When it makes money

What it costs to build

1. Executive summary

Most aesthetic clinics in South Africa run their front desk on WhatsApp, a phone and a diary. Some run on a booking tool that handles appointments adequately but was designed for another country. Both arrangements work, until they don’t.

They fail in two separate ways, and clinics usually only see the first one.

• Commercially. Cancelled slots stay empty, patients who are due for their next treatment quietly drift away, reminders depend on whoever is at the desk, and the owner finds out what happened to the month only when the month is over.

• Legally. Patient information sits in staff phones, spreadsheets and overseas servers with no consent record, no operator agreement, no retention rule and no audit trail. Aesthetic clinics handle health information – the most heavily protected category under POPIA – and the obligation sits with the clinic, not with whoever supplied the software.

IRIS is a front-desk and intelligence system built for clinics in that position, and built to be operated lawfully in South Africa. It runs the clinic’s bookings, reminders and patient conversations on the WhatsApp number patients already use. It keeps the patient record in South Africa. It brings every patient back when their next treatment is due, fills the slots that fall open, and gives the owner a short, plain-English brief each week on what to fix.

It is not a large practice-management platform and it does not try to be. It is deliberately narrow: the front desk, the patient relationship, and a defensible compliance position – done properly, rather than everything done adequately.

Why this matters to a multi-clinic operator

• One product, installed the same way at every clinic. Clinic facts change (practitioners, services, hours); the system does not.

• One compliance position across the group, rather than a different answer at every clinic depending on what that clinic happens to use.

• Every clinic keeps its own data, its own patients and its own permissions. A group view can be added on top, but no clinic depends on it.

• Measurable from week one: recovered slots, rebooked patients, no-show rate and response time, tracked against a baseline agreed before launch.

• Staged rollout: pilot at two or three clinics, prove the numbers, then roll out on a repeatable playbook.

2. What IRIS is

IRIS is four things working together, delivered as one system:

Who it is for

Clinics in South Africa and sub-Saharan Africa whose front desk is either nothing at all – a paper diary, a spreadsheet, someone’s phone – or a booking tool that handles appointments but was not designed for South African conditions: no local data residency, no operator agreement drafted to South African law, no support for the clinic’s own POPIA obligations, and a support desk in a distant time zone.

Who it is not for

• Clinics that need clinical charting, before-and-after image libraries, stock control, payroll or point-of-sale from a single vendor.

• Clinics already running well on a platform they are happy with, where the only gain would be marginal. IRIS is not worth a disruption for that.

• Clinics unwilling to change how the diary is kept. IRIS owns the diary; it cannot sit alongside a second, competing one.

What IRIS is not

IRIS deliberately does not do clinical charting, before-and-after photo storage, stock control, payroll or point-of-sale. Those belong to large all-in-one platforms and they carry materially heavier compliance obligations. IRIS stays focused on the part of the clinic where money is most often lost and where regulatory exposure is most often created without anyone noticing: the front desk and the patient relationship.

3. What IRIS does – a day in the life

The clearest way to explain IRIS is to follow one clinic through a working day.

Capabilities at launch

4. Why it matters – the cost of the current arrangement

Clinics running on WhatsApp and paper do not usually feel they have a problem, because the losses are invisible: slots that stayed empty, patients who never came back, hours on the phone, and an exposure nobody has quantified. The patterns below are typical; the Clinic Review measures the actual figures for your clinics.

A worked example

Assumptions for one clinic: three practitioners, 120 appointments a week, average treatment value R1,800, combined cancellation and no-show rate of 12%. These are illustrative; substitute your own numbers.

At an indicative R4,100 per month for a clinic this size, IRIS pays for itself on the first two or three recovered slots. The compliance position is not costed above: it is not a revenue line but a loss that does not happen.

5. How IRIS is different

An honest comparison. IRIS is not the most complete system on the market and does not claim to be. It is the most useful system for a South African clinic that wants its front desk to work and its data position to be defensible.

The five things IRIS does that matter most

1. Patient data stays in South Africa. This removes the cross-border transfer question rather than arguing it, and it is the one thing an overseas vendor cannot match without re-architecting.

2. Treatment-cycle rebooking. Aesthetic revenue is repeat revenue. IRIS knows when every patient is due and brings them back before they lapse. Generic booking tools do not do this.

3. Automatic slot recovery. A cancellation triggers the waitlist within seconds. The most direct, countable return on the subscription.

4. WhatsApp-first. Patients do not download an app or learn a portal. They message the number they already have.

5. A brief, not a dashboard. One page a week that says what changed, why, and the one thing to do. Every figure links to its evidence.

6. POPIA, safety and control

IRIS operates patient-facing communication and holds health-adjacent information, so control and privacy are designed in rather than added later. This section is written to be shown to your legal adviser.

Where responsibility sits

Under POPIA the clinic is the responsible party. PulseHealth, as the supplier of IRIS, is an operator processing personal information on the clinic’s behalf and on its instruction. That relationship must be recorded in a written agreement under section 21, and it is: an operator agreement drafted to South African law is signed before the first patient record is created.

This distinction matters commercially. No software can make a clinic compliant. What software can do is make compliance achievable, evidenced and cheap to demonstrate – which is what IRIS is built to do.

Data residency

The IRIS patient record – identity, contact details, appointments, treatment intervals, consent and conversation history – is stored in a South African cloud region. There is no routine transfer of the patient record outside the country.

Section 72 of POPIA does permit cross-border transfer in defined circumstances, and many clinics could lawfully use an offshore platform. IRIS takes the simpler route: if the data does not leave, the analysis does not have to be run, defended or revisited every time a vendor changes hosting.

Two constrained exceptions are stated openly rather than buried. WhatsApp message content necessarily transits Meta infrastructure, which is why the boundary rule below limits what may be sent. And the AI components that draft messages and compose the weekly brief are processed outside South Africa: they receive a first name, appointment facts and clinic-approved template text – never the patient record, clinical detail or images. Both exceptions are set out in the data-flow document and covered in the consent wording.

The WhatsApp boundary rule

WhatsApp is the reason patients engage and it is also a third-party channel operated by Meta. IRIS therefore draws a hard line about what may travel over it:

Anything sensitive is completed in the South African-hosted portal behind an expiring link. WhatsApp is a notification and light-transaction layer, not a patient record.

Special personal information

Information concerning health is special personal information under POPIA and may only be processed on specific grounds. POPIA is broader than the European GDPR in exactly the places an aesthetic clinic operates – it also names biometric information and pregnancy. IRIS reduces this exposure structurally by holding front-desk data only: no clinical notes, no images, no diagnoses. Where a service name is itself revealing, the clinic can configure IRIS to use a neutral label in outbound messages.

Human control

Every action IRIS can take sits at one of three authority levels, set by the clinic:

Clinical questions, symptoms, adverse-event references, complaints, sensitive circumstances and anything outside booking rules are always handed to a person. IRIS never gives clinical advice.

What the clinic receives for its own compliance

Included in activation, at no separate charge:

• A signed operator agreement drafted to section 21 of POPIA, under South African jurisdiction.

• A data-flow document showing exactly what is held, where, for how long and who can reach it.

• Consent wording for WhatsApp communication, and a consent register that records what was agreed, when and in what words.

• A PAIA manual template and guidance on registering an Information Officer with the Information Regulator.

• A data-subject request procedure – access, correction and deletion – with the export and deletion functions to service it.

• A breach-notification procedure and a retention schedule with automatic enforcement.

7. Build phases in plain English

IRIS is built in phases so that each clinic receives something useful early and the product grows only once the previous stage is proven. Clinics subscribe once; new phases arrive as product updates at no additional subscription cost, with the exception of the optional Group layer.

8. What the clinic pays

IRIS is priced on a two-part monthly subscription: a clinic platform fee, plus a fee for each treating practitioner. There are no tiers and no banded discounts. A five-practitioner clinic pays the same per practitioner as a two-practitioner clinic; only the number of practitioners changes.

The structure mirrors what IRIS actually costs to run. The platform fee covers what every clinic needs regardless of size – its own isolated environment, its own WhatsApp number, onboarding and a support relationship. The practitioner fee covers what scales with the size of the clinic: appointment volume, conversation volume and the intelligence built on top of them.

Subscription

Which produces:

Staff user accounts are not charged. Reception, managers and administrators are included – only treating practitioners count toward the subscription.

Group terms

A single operator running five or more clinics under one agreement receives a flat 12% discount on the total subscription. There are no further bands: the discount does not increase at 10, 25 or 50 clinics.

This is deliberate and worth stating plainly to an operator. Deep volume discounts on a service business transfer the benefit of scale to the buyer and leave the supplier under-resourced at exactly the point where support demand is highest. A modest, honest discount that holds at every scale is better for both parties than a steep one that quietly degrades service.

Once-off fees

Pilot pricing

Pilot clinics run on an introductory rate for the period before Phase 1 is fully released (see Appendix D):

Pilot billing is monthly only. Annual prepayment is not offered during a pilot: a clinic that can leave at four weeks is a stronger commercial position than a discount that locks in a clinic which is not yet convinced.

Monthly and annual billing

Pass-through costs

Two third-party costs are billed at cost and are not marked up:

• WhatsApp conversation fees charged by Meta. For a typical clinic these run R150–R600 per month depending on message volume.

• Payment-link transaction fees charged by the payment provider on deposits taken (typically 2.5–3% of the deposit amount).

Worked example – a 50-clinic group

Assuming the same mix used throughout this document: 20 single-practitioner clinics, 25 three-practitioner clinics and 5 six-practitioner clinics – 125 practitioners across 50 clinics.

Set against the recovery example in Section 4, where a single mid-sized clinic recovers an indicative R45,000 a month, the whole group subscription is covered by the recovered revenue of four clinics.

9. The Clinic Review

IRIS is not sold from a feature list. Every clinic works differently, and the honest answer to “will this help us?” cannot be given before someone has looked at how the clinic actually runs.

The Clinic Review is that look. It is a structured 90-minute assessment, run on site or by video with the owner or practice manager, followed by a short written report. It is the first step with every clinic, including pilot clinics, and it does three jobs at once.

What the clinic receives

Within five working days, a written Clinic Review Report containing:

1. A one-page picture of how the front desk currently works, in plain language.

2. A measured baseline: appointment volume, cancellation and no-show rate, estimated lapsed patients, and reception time spent on confirmations and reschedules.

3. An indicative recovery estimate built from the clinic’s own numbers – not the illustrative figures in Section 4.

4. A POPIA gap summary: what is in place, what is missing, and what carries the most exposure. Ranked, with the three items we would fix first.

5. A fit assessment: whether IRIS is the right answer for this clinic, and if it is not, saying so.

When we recommend against proceeding

The review is only credible if it can produce a “no”. We will say IRIS is not the right fit where:

• The clinic needs clinical charting or image storage from the same system.

• The clinic is contractually locked into a platform it is satisfied with, and the gain would be marginal.

• Appointment volume is too low for the subscription to be recovered from slot and rebooking gains.

• The clinic is unwilling to let one system own the diary, which makes the automation unsafe.

• There is no named person at the clinic who will own exceptions in the reception queue.

The full question set is at Appendix C.

10. Getting a clinic live

After the Clinic Review, activation is a four-step process designed to take two to three weeks of elapsed time and roughly four hours of the clinic’s own effort.

The WhatsApp connection, plainly

This is the part of onboarding that raises the most questions, so it is set out point by point.

The knowledge base – how it is created and loaded

The knowledge base is the clinic’s own approved information, and it is the only thing IRIS is allowed to answer patients from. It cannot answer from the open internet, from general medical knowledge, or from anything the clinic has not signed off. Where no approved answer exists, the conversation goes to the reception queue – IRIS never guesses.

1. Gather. During the Clinic Review, the raw material is collected: the service list with durations and prices, preparation and aftercare instructions, the five questions patients ask most (question C6), policies on cancellations, deposits and lateness, practitioner names, and practical details – hours, address, parking.

2. Write. Each item is rewritten as a short approved answer in the clinic’s own voice. Anything clinical is deliberately excluded at this step: a question about suitability, symptoms or complications is never answered from the knowledge base, however the entry is worded.

3. Sign off. The owner reviews and approves the full set. Nothing enters the knowledge base unapproved, and the sign-off is recorded.

4. Load. The approved set is loaded into the clinic’s own isolated knowledge base on the Azure platform – this is part of the contracted specialist work in Appendix A. Each entry is versioned, so what IRIS said on any given date can always be traced to what was approved at that date.

5. Maintain. Price changes, new services and revised policies are updated through the staff console – during the pilot, submitted through support and loaded the same day. Updates take effect immediately and are logged in the audit trail.

Existing patients and consent

Importing a patient list and being allowed to message those patients are two different things, and conflating them is the most common way a clinic creates exposure without noticing.

• The list is imported at step 2 from a spreadsheet or contacts export: name, mobile number, last visit, service and any forward bookings.

• Consent status is recorded honestly. Most clinics cannot demonstrate when or in what words an existing patient agreed to be contacted, and POPIA requires that consent be demonstrable rather than assumed. Where it cannot be shown, IRIS stores it as unknown.

• Unknown-consent patients are loaded but never messaged. The block is enforced in the software, not left to staff discipline.

• Consent is then collected the lawful way, as patients return: captured by reception at the next visit, or on the patient’s next inbound message, with the wording, date and channel recorded. Across one treatment cycle most active patients convert.

• There is no bulk opt-in message. Messaging someone without consent to ask permission to message them is precisely what the rule exists to prevent, and a clinic that does it has created the breach it was trying to avoid.

The existing diary

• Forward appointments already booked are entered at step 2 – date, time, patient, practitioner, service. Usually a few weeks’ worth, typed in where the diary is on paper.

• From step 1 the IRIS diary is the only diary. Anything booked at the desk or by phone goes in immediately; a parallel diary makes the automation unsafe.

• Historical appointments are not migrated. The treatment interval and the last-visit date give IRIS everything it needs to rebook a patient. Five years of appointment history adds nothing operationally and increases what the clinic is holding.

Staff access

• Logins are individual and never shared. A shared login destroys the audit trail, and the audit trail is what makes the compliance position evidence rather than assertion.

• When someone leaves, the clinic revokes their access in the console the same day. Front-desk turnover is a real exposure and it is asked about in the Clinic Review.

• Staff users are not charged for. Only treating practitioners count toward the subscription (Section 8).

What the clinic must have ready

The four-hour effort estimate holds when this list is ready before step 1. Most of it is captured naturally during the Clinic Review.

If calibration does not go well

Step 3 exists to find problems before patients feel them, and it is allowed to fail.

• If the diary is wrong, or reception is not using the queue, the answer is to stay in calibration rather than push on. Nothing is switched on to a deadline.

• Automated outreach begins only once confirmations have run clean for a full week and the named exception owner confirms the queue is usable.

• If the clinic decides to stop, it stops: full export of its data, deletion of the IRIS copy on a defined schedule, and its WhatsApp number released back to it. The same terms as the pilot exit in Section 11.

What does not happen at onboarding

• No hardware, and no software installation. Staff use a browser; patients use the WhatsApp they already have and download nothing.

• No migration of historical clinical records – IRIS imports patients, contacts and forward appointments only (Appendix B).

• No patient messaging during calibration beyond confirmations. Automated outreach is switched on only at step 4, after the diary has proven itself.

• No parallel diary. From step 1 the IRIS diary is the diary; running a second one alongside it makes the automation unsafe and is a reason to recommend against proceeding (Section 9).

11. Proposed pilot

We propose an eight-week paid pilot at two or three clinics, selected to represent the group’s typical size and service mix.

Pilot terms

• Introductory subscription of R750 per practitioner per month during the first release, moving to the standard rate once Phase 1 is fully delivered. Clinic platform fee, Clinic Review and activation all waived for pilot clinics.

• Baseline measured in the two weeks before go-live: appointments, cancellations, no-shows, lapsed patients, reception time on confirmations.

• Operator agreement and data-flow document signed and legally reviewed before any patient record is loaded.

• Weekly review call for the first four weeks, fortnightly thereafter.

• Either party may end the pilot at four weeks with no further obligation. On termination, the clinic receives a full export of its data and IRIS deletes its copy on a defined schedule.

Success measures

Decision point

At week eight, the pilot report shows baseline versus actual for every measure. If the numbers hold, the group rollout proceeds on the group terms in Section 8, at a pace of three to five clinics per fortnight.

12. Next steps

1. Discovery meeting: 60 minutes with the operator to confirm the pilot clinics, current front-desk practice, patient volumes and the numbers to be measured.

2. Clinic Review run at each pilot clinic; reports issued within five working days.

3. Pilot agreement and operator agreement signed; legal review of data handling completed.

4. Phase 0 begins. Pilot clinics live within six to ten weeks.

5. Eight-week pilot, weekly reporting, decision at week eight.

Appendix A – Build investment by phase

This appendix sets out the investment required to build and operate IRIS through each phase. It is included so that the operator can see that the roadmap is resourced and realistic, and to make clear which costs are fixed to the product and which scale with clinic numbers.

Figures are indicative and based on averages, current supplier rates and reasonable assumptions. They assume an exchange rate of approximately R18 to the US dollar for foreign-denominated services. Every line should be replaced with a written quotation before it is committed to.

Programme cost

The IRIS build is quoted as a single programme with four cost centres. All four are funded from the programme total; none sits outside it.

Basis for cost centre 1: approximately 860 hours of design and engineering at a blended rate of R720 per hour, reflecting AI-assisted delivery. A conventional development team building the same scope would be expected to cost two to three times this figure. Cost centre 2 is an indicative average for senior specialist contract work in this market and will be replaced with a written quotation before commitment. Cost centres 3 and 4 are drawn down over the rollout rather than spent at the outset.

Third-party, legal and contingency costs by phase

Notes

• There is no migration cost in this plan. A cheaper route exists: run the early phases on a low-code platform and move to proper infrastructure once the clinic numbers justify it. It has been rejected. That migration would cost R80,000–R150,000 and, far more seriously, would mean moving live patient records between platforms while clinics are trading on them. Building on the correct architecture from Phase 1 costs more early and removes that risk entirely.

• Platform and AI costs at 50 clinics are estimated at R56,000 – R65,000 a month, against group subscription revenue of roughly R157,000 (Section 8 example). The economics support a dedicated support function and ongoing development.

• Support is the cost most often underestimated. From roughly the tenth clinic, a dedicated support person is assumed within the running costs above; the subscription is set to carry it.

• Total indicative investment to reach a 50-clinic platform: a programme cost of R900,000 – R940,000, plus R80,000 – R160,000 of third-party, infrastructure and legal costs across Phases 0 to 4.

• Cost centre 4 is not permanent working capital. Appendix E sets out the clinic count at which subscription revenue covers deployment capacity and ongoing development, after which contingency is no longer drawn for operations.

Appendix B – What IRIS deliberately does not do

Stated plainly so that expectations are correct from the first conversation.

Appendix C – The Clinic Review

The full question set. Run on site or by video with the owner or practice manager, in roughly 90 minutes. Sections A to H establish how the clinic works and what it is losing. Section I establishes the compliance position. Sections J and K close the assessment.

Ask the question as written, then stop talking. The value is in what the clinic volunteers after the answer.

A. Clinic profile

B. The diary today

C. Patient communication today

D. The patient record

E. Money, deposits and no-shows

F. Repeat treatment and retention

G. Lead flow and marketing

H. People and roles

I. POPIA position

Ask these plainly and without alarm. The purpose is assessment, not pressure. Record the answer, not a reaction.

J. Existing systems and constraints

K. Priorities and definition of success

Fit scorecard

Completed by the reviewer immediately after the session, before writing the report.

Appendix D – Phase 1 build specification

D1. Why Phase 1 is split

Phase 1, as described in Section 7, is a single 6–10 week build covering the diary, booking, confirmations, waitlist, rebooking, deposits, reception queue, consent register, audit trail and weekly brief. That is too much to fund before anything is proven and too much to release at once into a live clinic.

Phase 1 is therefore built in two sequenced releases, 1A and 1B. Both remain “Phase 1” to the clinic: one subscription, both releases included, exactly as promised in Section 7. The split is a build sequence, not a pricing tier.

• It shortens the distance to a paying clinic. 1A is the smallest release a clinic will pay a monthly fee for.

• It separates the countable win from the slow one. 1A produces recovered slots – visible in week one and arguable in rands. 1B produces retention revenue and owner insight, which need eight to twelve weeks of data before they can be demonstrated at all.

• It changes the funding conversation. Negotiating investment for 1B from a working 1A at two clinics is a different discussion to negotiating from a document.

D2. Phase 1A – the front desk that pays for itself

Build window 5–7 weeks. Goal: one clinic runs its entire booking operation on IRIS and can count the slots it recovered.

Out of scope in 1A

Treatment-cycle rebooking, the weekly brief and deposit links move to 1B. Digital intake forms remain in Phase 2; everything in Phases 3 and 4 is unchanged.

Deposits move to 1B despite appearing in the original Phase 1. Payment-provider integration adds a third-party dependency, a reconciliation surface and a support burden, for a benefit that only becomes visible in a no-show rate measured over eight weeks or more. Waitlist auto-fill is a bigger, faster and cheaper win. If a pilot clinic makes deposits a condition of signing, move it forward – it costs roughly a week and buys nothing measurable in the first month.

Compliance items that cannot be deferred

These are built into 1A rather than added later, because retrofitting any of them means rebuilding around live patient data:

• South African-hosted database with per-clinic isolation, from the first record.

• Operator agreement signed before any patient data is loaded.

• Consent register live before the first outbound message.

• Audit trail live before any automated action.

• The WhatsApp boundary rule (Section 6) enforced in code rather than in policy: no clinical detail, no images, no forms over WhatsApp.

D3. Phase 1B – retention and intelligence

Build window 4–5 weeks, starting only after 1A has run four or more weeks in live clinic operation. Goal: the clinic earns money from patients it would otherwise have lost, and the owner knows why the month went the way it did.

Rebooking and the brief ship together rather than separately. Rebooking without the brief is automation nobody trusts, because the owner cannot see what it did. The brief without rebooking is a report about a problem nobody is fixing. They are one release.

D4. Build sequence and gates

Total elapsed time to a fully proven Phase 1 is roughly 20–26 weeks including live running, against 6–10 weeks of build in the original plan. The build effort is almost identical; what has been added is the time IRIS spends being watched in a real clinic before anything is stacked on top of it.

D5. The technology stack

Selected against three constraints, in order: patient data resident in South Africa; buildable and maintainable by a one-person practice using AI-assisted development; and low fixed cost until clinic numbers justify more.

Two deliberate exclusions

• No low-code database platform in the patient path. Airtable and equivalents host outside South Africa and cannot offer per-clinic isolation at the level required. They remain useful for internal pipeline and admin tracking that contains no patient information.

• No general automation platform in the patient path. Make.com processes in its EU or US zones. Routing patient data through it would create a cross-border transfer that the architecture is specifically designed to avoid. Make remains appropriate for internal notifications and back-office automation that carries no clinic data.

This is the main practical cost of the compliance position: more is written in code and less is assembled from convenient tools. It is also why the development estimate is higher than a low-code approach would have been.

D6. What the stack means for the POPIA claims

Section 6 states that the patient record is stored in South Africa. That remains accurate, and this section states precisely what does and does not leave the country, so that the claim can be defended rather than merely asserted.

D7. Development effort and cost

Phase 1 development is split between in-house engineering (cost centre 1) and contracted specialist work (cost centre 2). In-house engineering is charged at a blended rate of R720 per hour. Only the contracted portion is cash out of the business during the build – a distinction that matters for D8 and for any funding discussion.

The contracted portion covers WhatsApp Business Platform integration and the knowledge-base build, carried out on Microsoft Azure by an external developer. R100,000 is an indicative average for three to five weeks of senior contract work in this market; the realistic range is R80,000 to R150,000 and it must be replaced with a written quotation before the build is committed to. The conditions in Appendix A – Azure subscription held by PulseBrands, IP assigned, sub-operator agreement signed, scope fixed – apply before any work starts.

The combined figure is R18,000 higher than a single-release Phase 1 would be. That difference is the cost of releasing twice: a second calibration cycle, a second round of clinic training, and regression-testing 1A when 1B lands. It is cheap for what it buys.

D8. Cash requirement

Separating cash out of the business from development time changes the funding picture materially.

Phase 1A – to two clinics live and paying

Phase 1B – incremental

D9. Running costs borne by PulseHealth

Monthly, once clinics are live. Fixed platform costs do not scale with clinic numbers; AI usage does.

D10. What the clinic pays during the pilot

Monthly only. Annual prepayment is not offered during the pilot: a pilot the clinic can leave at four weeks is a stronger commercial position than a discount that locks in a clinic which is not yet convinced, and it is consistent with the exit terms in Section 11.

D11. Where the model breaks even

Set out in full in Appendix E, which works through operating break-even, sustainable break-even, the start of the profit journey and investment payback on the two-part subscription described in Section 8.

D12. Risks introduced by the split

Appendix E – Break-even and profit

E1. Three different break-evens

“Break-even” is used loosely and it hides the number that actually matters. There are three, and they occur at very different clinic counts.

E2. Complete cost overview

Every cost carried by IRIS, in one place. Figures are indicative and based on averages, current supplier rates and reasonable assumptions. Each should be replaced with a written quotation or an actual invoice as it becomes available.

Read the scope of each table carefully, because they differ. E2.1 covers the whole programme, Phases 0 to 4, not the pilot alone. E2.2 and E2.3 are scale-based rather than phase-based: they show what it costs to run at two to ten clinics against twenty-five to fifty, in whichever phase the product happens to be. E2.5 shows when the one-time cash is actually needed. The pilot-only cash figure is in D8.

There is no capital cost for a South African data centre. IRIS rents capacity in Microsoft’s South Africa North (Johannesburg) region. Data residency is therefore an operating cost, not an asset to be built – which is precisely why it is affordable for a business of this size.

E2.1 One-time programme and build costs

E2.2 Recurring fixed costs – borne by PulseHealth

The compliance and data layer, in Azure South Africa North. These costs do not scale with clinic numbers; they step up at capacity thresholds.

E2.3 Recurring variable costs – per clinic

E2.4 Who bears what

E2.5 When the one-time cash is needed

The one-time total in E2.1 is not required at the outset. It is drawn down across the phases, and a large part of it only arises once clinics are live and paying. This table shows the cash portion only – in-house engineering is charged to the programme but is not cash out of the business.

E3. Assumptions used in the model

The break-even arithmetic that follows uses the midpoints of E2. Change any of these and the answer changes. They are conservative rather than optimistic.

Pass-through costs – WhatsApp conversations and payment transaction fees – are excluded from the model entirely, because they are billed to the clinic at cost and are neither revenue nor cost to PulseHealth.

E4. Monthly position by clinic count

Independent clinics at full tier, no group discount applied.

The two dips are deliberate and both are staffing steps, not failures of the model: support arrives at ten clinics and again at twenty-five. Each is recovered within two to three additional clinics.

E5. The answers

Cash-only payback

If in-house engineering is treated as retained value rather than a cost to be recovered, only the R196,000 – R335,000 of actual cash needs repaying. At eight clinics, generating R14,150 per month, that is repaid in fourteen to twenty-four months. At fifteen clinics it falls to eighteen to thirty-one months because a support salary has been added – a reminder that faster growth does not mean faster payback across the staffing steps.

E6. When programme contingency becomes redundant

Programme contingency (cost centre 4 in Appendix A) exists to fund what revenue cannot yet cover: deployment and support capacity, unforeseen specialist work, and legal or regulatory surprises. It is not permanent working capital, and it should have a defined end.

The test is simple. The reserve stops being needed for operations once monthly contribution covers the support cost already in the table above plus a standing allowance of R20,000 a month for ongoing development.

E7. Why the group discount is flat

Section 8 offers a single operator with five or more clinics a flat 12% discount, with no further bands at 10, 25 or 50. That is a deliberate choice and it is worth being able to defend it in the room.

The instinctive structure is a tiered one – deeper discounts as the group grows. On a service business it does the opposite of what it looks like it does. Support demand, AI cost and onboarding effort all rise with clinic numbers, so the point at which a tiered scheme gives the most away is the point at which delivery costs the most. The supplier ends up under-resourced exactly when the group is largest and most visible.

The table below shows the effect at fifty clinics, comparing the flat rate against a conventional 30% volume discount and against the same number of clinics won one at a time.

A 30% tier would leave a fifty-clinic group earning barely a tenth of what forty independent clinics earn, on considerably more support load – a rollout that looks impressive and is not worth doing. The flat 12% keeps the group meaningfully cheaper per clinic than buying individually, while leaving enough margin to staff the support the group itself creates.

E8. The remaining levers

In order of how much they move the outcome.

E9. The hiring trap

At around ten clinics the monthly position goes briefly negative because a support person has been added before the revenue from those clinics has grown to absorb the cost. The obvious response is to postpone the hire and carry the load personally for a few more months.

That is the most expensive saving available in this plan. Clinics eleven to fifteen are the ones deciding whether the operator continues the rollout, and they talk to each other. Support degrading at that exact moment does not cost one clinic; it costs the rollout, and with it every clinic that would have followed.

Plan the hire as part of reaching ten clinics rather than as a reaction to having reached them. The dip is roughly R500 to R3,000 a month for two months. It is a rounding error against what it protects.

E10. The strategic conclusion

The arithmetic above points to something that is not obvious from the clinic-facing sections of this document, and it should shape how the next twelve months are spent.

Appendix F – Plain-English glossary

Every term used in this document that is not everyday English. No prior knowledge of software or privacy law is assumed.

The business

The technology

The law

The money

Appendix G – Consolidated risks

Risks appear throughout this document alongside the sections they affect. They are gathered here in one place so that they can be weighed together rather than encountered piecemeal.

This list is deliberately complete rather than reassuring. A venture at this stage carries real risk, and a document that hid it would be less useful to you, not more.

Commercial

Delivery

Regulatory

Financial

Appendix H – Questions worth asking

These are the questions a careful investor or partner should put to PulseHealth before committing anything. They are included because informed scrutiny is more useful than polite agreement, and because a plan that cannot survive them is not ready.

Every one has an answer somewhere in this document, but the answers should be given in person and tested.

On the market

On delivery

On the numbers

On the structure of any agreement