Terms of Service

Status: DRAFT. Not yet in force. This document has been written from the source code of the product it describes, and has not yet been reviewed by a lawyer. Every place a term could not be established from the software is marked ⚠️ DECISION NEEDED. Do not publish it, link to it, present it at signup, or rely on it until those are resolved and a qualified reviewer has signed it off.

Last updated: ⚠️ DECISION NEEDED: set the date this is approved, not the date it was drafted.

1. Who this agreement is between

These terms are between you — the business that opens a HeyThula account — and us: Learn App (Pty) Ltd, a private company registered in South Africa, registration number 2020/142526/07, of 173 Oxford Road, Rosebank, 2196, South Africa — the address for service of legal notices under section 16.

We trade as HeyThula and operate heythula.com, the application at app.heythula.com, the widget served from cdn.heythula.com, and help centres at *.help.heythula.com.

By creating an account you accept these terms. If you are accepting on behalf of a company, you confirm you are allowed to bind it.

⚠️ DECISION NEEDED: acceptance is still not recorded, though half the problem has since been fixed. Email verification has shipped — an email/password signup is sent a confirmation link, and a Google signup arrives already verified — so we can now show that an address belongs to the person who typed it. What is still missing is any record that they agreed to this document: the signup form has no terms checkbox, no link to these terms, and nothing about agreement is written to the account when it is created.

A checkbox at signup, storing the document version and the timestamp on the account. The strongest evidence, one extra click, and the only version that answers "which wording did they actually accept?" when a term is later disputed or changed.
Sign-up-wrap: "By creating an account you agree to the Terms and Privacy Policy" beside the button, with both links. No extra click, generally upheld where the links are conspicuous and next to the action, and the smallest thing worth shipping.
Agreement by use. Weakest, hardest to prove, and it is what is happening today by default rather than by decision.

The second is the minimum that stops this being an accident; the first is what an enterprise buyer's counsel will ask for. Either way, record the version accepted — without it, section 13's change-of-terms notice has nothing to compare against.

2. What the service is

HeyThula is customer-support software. The account you open gives you:

A chat widget you embed on your own site or in your own product.
A shared inbox where your team reads and answers those conversations.
An AI assistant that answers your customers' questions using only your published help articles, and hands the conversation to a human when it cannot.
A public help centre, served on a subdomain of help.heythula.com that you choose.
Contacts and lead capture, so you keep a record of who you have spoken to.
Email notifications, so replies reach people who are not looking at the widget, and so they can reply by email.
An article importer that copies your existing help-centre articles across from Intercom.
A guide recorder that watches you perform a task in your own product and drafts a help article from it.

We change and improve the product continuously. We may add, alter or remove features.

[DEFAULT — confirm] Before we remove or materially reduce a feature that a paid plan depends on, we give 30 days' notice by email to account owners. Two things are outside that: anything labelled beta or experimental, and a removal we have to make immediately for a security or legal reason.

Why 30 days: it is the same period as every other notice in these terms, so there is one number rather than five, and it is long enough for a customer to object or move without being long enough to freeze the product. Note the practical limit — with no export function, "30 days to move" currently means 30 days to plan, not 30 days to take your data with you. See section 11.

3. Your account and your team

You are responsible for what happens under your account, including everything your team members do.

The person who signs up becomes the account owner. Owners can invite admins and agents, and can control which workspaces each person sees.
Keep sign-in credentials secure. Tell us promptly if you think an account has been compromised.
Two-factor authentication — a one-time code from an authenticator app, with backup codes for a lost phone — is available and we recommend it, particularly for owners and admins. An agent account can read every conversation in the workspaces it can see.
Each plan includes a fixed number of seats and workspaces (see section 4).

You must give accurate account information and keep it current.

4. Plans, usage and billing

The product meters AI resolutions. One conversation the AI handled is one resolution, however many messages it took. A conversation your team answers — including one the AI started and then handed over — does not count.

The plans, as implemented in the software:

Free — 1 seat, 1 workspace, 50 AI resolutions per period, no charge.
Pro — 3 seats, 2 workspaces, 500 AI resolutions per period, $39 per month.
Scale — 8 seats, 5 workspaces, 2,000 AI resolutions per period, $129 per month.
Agency — 25 seats, 50 workspaces, 10,000 AI resolutions per period, $299 per month.

Three things about how the limit behaves, because the differences matter:

Free is a hard stop. When a Free account reaches 50 resolutions in a period, the AI stops answering and every conversation goes to a human. Nothing is charged and nothing breaks — your team simply answers everything until the period resets.
Paid plans meter overage and never switch off. Past the included number, resolutions are charged per resolution: $0.70 on Pro, $0.50 on Scale, $0.30 on Agency. The AI keeps working.
A Free account gets 5 AI answers before its owner's email address has to be confirmed. This is separate from the 50, sits well below it, and will be the first limit a new Free account meets. Until an owner's address is confirmed, the AI answers the first 5 questions on the account and then, from the sixth, hands every conversation to a human exactly as if the plan limit had been reached (firebase/functions/src/ai/handleMessage.ts). Confirming the address — the link we email at signup — lifts it from the next question onwards, and a Google sign-in arrives already confirmed and never meets the gate at all. It stays lifted while that address stays confirmed: we re-check with the identity provider periodically, so deleting or moving the confirmed address brings the gate back. This is an anti-abuse measure on a self-serve signup, not a plan entitlement, and we may change the number.

It counts attempts, not resolutions, and the difference is not in your favour. One of the 5 is spent when the AI tries a question, whether or not the answer turned out to be useful and whether or not the conversation was ever resolved. The 50 counts something else entirely — conversations the AI actually resolved, tallied when the conversation closes — so an unconfirmed account can be stopped at 5 while its resolution counter still reads 0.

Usage is counted per account and shared across all your workspaces — not per workspace, and not on the first of the month. When the counter resets depends on whether you pay us:

On a paid plan it resets when an invoice is paid (firebase/functions/src/billing/applyEvent.ts). Your period is Stripe's billing period, so it is a calendar month — 28 to 31 days — rather than a fixed 30, and each paid invoice for your subscription starts a fresh one.
On Free it resets 30 days after the period started, on a daily sweep (firebase/functions/src/billing/resetFreeUsage.ts), because a Free account gets no invoices to reset it. A Free period is therefore a fixed 30 days and drifts against the calendar.

Payment is taken through Stripe. You provide card details to Stripe on its own hosted checkout, and manage your subscription in Stripe's billing portal. We never see or store card details.

[DEFAULT — confirm] Billing currency and VAT. Prices are quoted and charged in US dollars, and are exclusive of VAT: where South African VAT applies, it is added at checkout and shown on the invoice. A referral credit is issued in the platform currency regardless of what the customer was invoiced in.

Why USD-exclusive rather than the alternatives:

Keep USD. What software buyers expect, nothing to re-price, and Stripe handles conversion. The plan table in the code is already USD, so this is the only option that changes no code.
ZAR for South African customers, USD elsewhere. Cleaner for local invoicing and friendlier locally. Two price lists to keep in step, a change to the plan table, and it buys very little while most customers are not South African. Worth revisiting if that stops being true.
Quoting VAT-inclusive. Tidy for a South African audience and wrong for everyone else, because a single inclusive price is only inclusive in one country.

The entity is now known — Learn App (Pty) Ltd, South African — so what follows is settled:

VAT registration is compulsory above R1 million of taxable turnover in any consecutive twelve months, and voluntary above R50 000. Either way it is a fact about the company, not a choice made in this document.
If the company is registered, VAT is charged on supplies to South African customers. Supplies of services to a non-resident customer who is not in South Africa at the time are generally zero-rated, so a foreign customer's USD price does not change — which is exactly why exclusive pricing is the right default here.
If the company is not registered, no VAT is charged and no invoice may show any, and the threshold has to be watched, because crossing it is not optional and is not noticed automatically.
Stripe Tax can compute, collect and show this correctly. It is not switched on. Until it is, an invoice to a South African customer is wrong the moment the company is registered.

⚠️ DECISION NEEDED — a fact we do not have, not a judgement call: is Learn App (Pty) Ltd registered for VAT? Nothing in the codebase or in the founder-supplied details answers it. If it is, the VAT number belongs on invoices and in section 16, Stripe Tax has to be configured before the next invoice, and the pricing page has to say "excluding VAT". If it is not, say nothing about VAT anywhere and put a threshold check in somebody's calendar.

⚠️ DECISION NEEDED: what a cancellation does, and what is refundable. Stripe's portal is the only cancellation path in the product, and nothing in the code chooses between these.

Cancel at period end, no refund. The default across the industry. The customer keeps what they paid for until the period runs out and there is nothing to reconcile.
Cancel immediately with a pro-rata refund. Friendlier, more support handling, and it invites cancel-and-return churn on a monthly plan.
Period end, plus a no-questions refund inside the first 14 or 30 days. Removes the objection at the point of purchase, and at these prices costs very little.

The first or the third. Note that neither survives contact with consumer law unchanged: in South Africa the Consumer Protection Act lets a consumer cancel a fixed-term agreement on 20 business days' notice and caps the cancellation penalty; in the EU and UK a consumer has a 14-day right of withdrawal, waivable for immediately-supplied digital services only if they are asked properly. Most of that falls away if we only ever sell to businesses — which is itself worth deciding out loud, because a sole trader signing up is a consumer under several of these regimes.

[DEFAULT — confirm] Failed payment. Not implemented — this is the policy to build to. Stripe retries a failed card over roughly two weeks and emails the customer, and everything keeps working throughout. 14 days after the first failure, an account that still has not paid drops to the Free plan's limits: the AI stops after 50 resolutions in a period and every conversation goes to a human. Nothing is deleted, nothing is locked, and paying reinstates the plan immediately.

Why: 14 days is about what Stripe's own retry schedule takes, so the product and the payment processor do not disagree about when the grace period ended. And dropping to Free rather than suspending matters more than it sounds — suspension would take a business's support queue dark because a card expired, which is how we would lose the customer we were trying to collect from. The software syncs subscription status from Stripe today and acts on none of this.

[DEFAULT — confirm] Price changes. We give 30 days' notice by email to account owners before a price increase, and it takes effect from the start of the next billing period after the notice ends. Anyone who does not want it can cancel before then. Price decreases and new plans apply straight away.

Why notice plus an exit rather than notice alone: a term letting one side rewrite the price while the other is locked in is the first thing a consumer regulator strikes out, and in South Africa it is squarely what the Consumer Protection Act treats as unfair. 30 days matches every other notice period here.

Referrals

Every account has a referral code. The programme only runs while it is switched on; while it is off, codes are still recorded for attribution but nothing is granted and nothing is promised.

What the software actually does, which is the offer:

The friend gets their first month free — a discount applied at checkout, once per account. It is marked used on their first invoice, so cancelling and subscribing again does not earn it a second time.
The referrer gets one month of their own plan as account credit — the monthly price of whatever plan the referrer is on, credited to their Stripe balance, once per referred account. It is granted only when the friend makes their first real payment, not on the $0 first invoice, so a signup that never pays for anything earns nobody a reward.
A referrer on the Free plan gets nothing, because there is no subscription to credit. The referral is still recorded.

[DEFAULT — confirm] The rules the code does not encode, and needs: credit has no cash value and is not refundable or transferable; we may withhold or reverse it for self-referral, for bulk or automated signups, or for any account that exists to farm it; and we may change or end the programme at any time, honouring credit already granted.

Why those four: they are what every referral programme is eventually abused for, and the code defends against only one of them (requiring a real payment). Separately, confirm that the referrer's credit is meant to scale with the referrer's plan rather than the friend's — as built, an Agency referrer earns $299 of credit for introducing a $39 Pro customer, and that is a pricing decision hiding in an implementation detail.

5. Your data, and your customers' data

You own your content. Your help articles, your branding, your contacts, your conversations and everything else you or your customers put into the product remain yours. We claim no ownership of it.

We hold your customers' data on your behalf. When your customers chat through your widget, you are the responsible party under POPIA and the controller under GDPR; we are the operator / processor. We process that data on your instructions, to run the service, and for no purpose of our own. What is stored, where it sits and who else touches it is set out in the Privacy Policy.

You are responsible for the lawful basis. You decide what to collect from your customers, what to put in custom attributes, and what your own privacy notice tells them. You must have the right to give us the data you send us, and you must tell your own customers that you use a support tool that processes their messages — including that an AI reads them.

Do not send us data you should not. In particular, do not put special-category or sensitive personal information into contact attributes, and do not use the guide recorder over live customer data or payment details. The recorder discards values from fields that look sensitive and blacks out that area of the screenshot, but a customer's name sitting in a list is not a password and nothing will mask it.

⚠️ DECISION NEEDED: this section describes a processor relationship that is not yet contracted. POPIA s21 requires a written operator agreement; GDPR Art. 28 requires named terms — sub-processor consent, help with data-subject requests, deletion or return at the end of the contract, and audit rights. None of it exists. The three ways to paper it, and the recommended one, are set out in the Privacy Policy under "Who is who"; the choice is made once and binds both documents. Referring to a DPA here is not a substitute for having one.

[DEFAULT — confirm] On deletion, we can now commit, because the software can now do it: an account owner or admin can delete a workspace from its settings at any time, and everything in it — conversations, contacts, help articles, uploaded files and the public help centre — is permanently erased after a 7-day cancellable grace period. On request we will do the same for a whole account. Deleted content can persist in backups for up to 14 weeks before ageing out, and we do not restore a backup in order to recover something that was deleted on purpose.

⚠️ DECISION NEEDED: whether we commit to an export. There is no export function of any kind, so anything said here is a promise to build one.

No commitment, said plainly. Honest, and it is what a customer gets today. It also means a GDPR Art. 20 portability request has to be answered by hand every time.
A manual export on request, within a stated number of days. Costs a script and somebody's afternoon. It is what a portability request and a departing enterprise customer will force anyway, so building it deliberately beats building it under a deadline.
Self-serve export, built before these terms are published, and committed to here. The right end state and the most work.

The second is the smallest defensible commitment — and note that a DPA promising "deletion or return" is not true without at least that much.

6. What you may not do

You must not, and must not let anyone else:

Use the service to send spam, or for unsolicited marketing to people who have not agreed to it.
Upload or transmit anything unlawful, or anything that infringes someone else's rights.
Impersonate anyone, or set up the widget so that it misleads your customers about who or what they are talking to. Specifically: you may not present the AI as a human being. The product labels it as an AI and you must not work around that.
Attempt to access another customer's workspace or data.
Probe, scan or test the security of the service, or interfere with its operation.
Reverse-engineer the service, or copy it to build a competing product.
Resell or sublicense access to the service.

⚠️ DECISION NEEDED: the Agency plan and the bullet above contradict each other, and the contradiction is in the product's own commercial design rather than in the drafting. Agency is 25 seats and 50 workspaces for $299 — a shape that only makes sense if one business is running support for fifty others — while "resell or sublicense access to the service" is forbidden three lines up. One of the two has to move.

Carve out the Agency plan. Reselling permitted on Agency only; the agency stays our customer and stays liable for what its clients do; the agency is the responsible party / controller for each client workspace unless it agrees otherwise with us in writing; the prohibition still bites everywhere else. Matches what the plan is evidently built for.
Keep the prohibition and re-describe Agency as "your own brands, regions or business units — not clients". Honest only if we then police it, and it makes the plan much harder to sell.
A separate partner or reseller agreement for agencies, leaving these terms alone. What larger platforms do; it is a second document to write and keep current.

This has to be settled before an agency signs up, because the answer decides who owes the end client a DPA — us or the agency — and that is not something that can be fixed afterwards.

Use automated means to extract data from the service beyond your own account's data.
Use the service in breach of export controls or sanctions.

We may suspend an account that is causing harm to the service or to other customers, without notice if the harm is immediate.

7. How the AI behaves, and what we do not promise

We are specific about the AI because vagueness here would be a promise we cannot keep.

It answers only from your published help articles. Not from the internet, not from a general model's knowledge, not from other customers' content. If nothing you have published covers a question, it does not answer — it hands the conversation to a human. An empty help centre means every conversation goes to a human.

It shows its sources. Each AI answer names the articles it used.

It also stops for reasons that are not about the question. It hands over when your account is at its plan limit, when it has already replied the maximum number of times you allow in one conversation, and — on a Free account whose owner has not confirmed their email address — after the first 5 answers. All three are set out in section 4.

It always identifies itself as an AI. This is enforced in the widget.

It is not perfect. It is a language model. It can misread a question, miss an article that would have answered it, or summarise one of your articles inaccurately. We do not warrant that its answers are correct, complete or suitable for any purpose, and you should not use it for advice where an error would cause harm — medical, legal, financial or safety-critical.

You are responsible for what it says on your behalf. It answers in your name, from content you wrote and published. Review what you publish.

You control it. You can switch the AI off entirely, cap how many times it replies in one conversation, and every conversation can be taken over by a human at any time.

8. The article importer

If you import articles from Intercom, you give us a token to read your Intercom help centre. By doing so you confirm you are allowed to.

We use it read-only, we read only help-centre articles, collections and their images — never conversations or contacts — and we delete the token when the import finishes, when you cancel it, or automatically if it stalls. The deletion time is shown to you.

Imported articles are your content, subject to whatever rights you had in them already. We take no responsibility for the accuracy of the conversion; review imported articles before publishing them.

9. Availability

We work to keep the service running and we watch it, but we do not promise it will be available without interruption. It depends on Google Cloud, and on Stripe, Postmark and Anthropic's models served through Google, any of which can fail.

There is no service level agreement, no uptime commitment, and no status page. We would rather say so than imply one exists.

⚠️ DECISION NEEDED: whether to offer a service level agreement on paid plans, and whether to stand up a real status page. There is neither today, and the paragraph above says so.

No SLA. The correct answer while there is one region, no status page and nobody formally on call. It is what the drafting above already commits to, and it will cost deals with buyers whose procurement asks the question.
An uptime commitment with service credits — typically 99.9% a month, credited as a percentage of that month's fee, capped, and claimed by the customer. The usual first SLA. It needs measurement we do not have: an uptime figure nobody computes is worse than no figure at all, because the first dispute exposes it.
An uptime target with no credits. Reads as reassurance to a small buyer and as evasion to a large one, and it buys neither the trust of the first nor the deal from the second.

The first, until there is a status page and a way to measure. Note that docs/marketing/site-pages.md already flags that the marketing site plans to link to a status page that does not exist, and correctly says it must never be faked. An uptime number nobody measures is that same mistake written into a contract.

10. Intellectual property

The service, the software, the widget, our brand and everything we have written about the product are ours (or our licensors'). These terms give you a limited, non-exclusive, non-transferable right to use the service while your account is open and on one of the plans we offer — the Free plan included. The licence is exactly as wide as the account and no wider: it ends when the account closes or these terms terminate, and it is suspended for as long as the account is suspended under section 6 or section 11. Falling behind on a paid plan does not end it on its own — under section 4 the account drops to the Free plan's limits, and the Free plan is licensed. Nothing more transfers.

You keep everything you put in — see section 5.

If you send us feedback or suggestions, we may use them to improve the product without owing you anything for it.

The widget carries a small "Powered by" link to us, under the conversation and at the foot of the home screen. On the Free plan it stays. On a paid plan — Pro, Scale or Agency — you may remove it, by setting hidePoweredBy either in the embed snippet's Support.init options or on your workspace's public branding document. There is no toggle for it in the dashboard yet, so switching it off means editing the embed snippet or the branding document directly.

Removing it is checked against your plan, and the check is not made in the code we hand to your page: your entitlement is written by us, from your account's plan, to a document your workspace cannot edit. If your account is on Free, or has just been downgraded, the widget shows the attribution whatever the snippet or the branding document ask for. If we cannot determine your plan for any reason, the attribution is shown — the check fails in that direction on purpose.

Two honest limits on that sentence. The first: the widget is JavaScript running on your page, so anyone who controls that page can remove the link from the browser whatever our servers say. We have not tried to prevent that and could not. What the check gives us is that no supported route removes the attribution without the entitlement — so doing it anyway is a breach of this section rather than a feature we shipped you. The second: the entitlement follows your plan, so if you cancel or downgrade, the attribution comes back the next time a visitor loads the widget.

11. Ending the agreement

You may stop using the service at any time, and cancel a paid subscription through Stripe's billing portal.

We may terminate or suspend an account that materially breaches these terms.

[DEFAULT — confirm] We give 30 days' written notice of a material breach and terminate only if it has not been put right by the end of it. Two things take effect immediately instead: non-payment, once the failed-payment window in section 4 has run, and anything causing active harm — the conduct in section 6, a security threat, or unlawful content. You may stop at any time, for any reason, by cancelling.

Why 30 days: it is the standard commercial cure period, and it is long enough that a customer who is willing to fix something can actually do it. Pairing it with an immediate right for active harm is what stops a cure period becoming a reason we cannot act when we have to.

What happens to your data afterwards. You can delete a whole workspace yourself from its settings — an owner or admin types the workspace's name, the workspace keeps working for a 7-day grace period that the deletion can be cancelled in, and after that everything in it is permanently erased: conversations, contacts, messages, help articles, uploaded files, the public help centre and every registry entry that named it. What the product still cannot do is delete a single contact, conversation or message, delete an account as opposed to a workspace, or export anything at all. Those we do by hand, on request. Deleted data can persist in backups for up to 14 weeks.

[DEFAULT — confirm] Not implemented — this is the policy to build to. When an account closes, or a paid subscription lapses and is not restarted, we keep its data for 90 days and then delete it. During that window a customer can come back and find everything as they left it, or ask us for a copy. After it, the workspaces are purged the same way a customer's own deletion purges them. Backups age out on their own inside 14 weeks.

Why 90 days: it covers the customer who cancelled by mistake, the card that failed while somebody was on leave, and the slow decision to come back — and it is short enough that we are not holding a former customer's customers' conversations indefinitely, which is what POPIA s14 and GDPR Art. 5(1)(e) are about. It must stay the same number as the Privacy Policy uses, because they are describing one policy.

12. Warranties, liability and indemnity

⚠️ DECISION NEEDED: this section has to be drafted by a lawyer, against South African law as defaulted in section 14. Nothing in it can be derived from the codebase, and a wrong limitation clause is worse than none — the Consumer Protection Act restricts exclusions and requires certain terms to be conspicuously drawn to a customer's attention, and consumer law in the EU and UK overrides exclusions that reach too far.

Most of it is standard and needs no decision: the service provided "as is", implied warranties of fitness and merchantability disclaimed as far as the law allows, indirect and consequential loss excluded, the un-excludable carve-outs preserved (death or personal injury caused by negligence, fraud, and whatever else the governing law protects), and a customer indemnity for their own content and their use of the service.

Three things are genuine choices rather than boilerplate:

How big the liability cap is. "Fees paid in the preceding 12 months" is the norm, and on a $39-a-month plan that is $468 — small enough that a serious buyer's counsel will push back. The usual compromise is a floor: the greater of 12 months' fees or a stated amount. Pick the amount now, in the quiet, rather than during the first enterprise negotiation.
Who carries the risk of a wrong AI answer given to a customer's customer in the customer's name. The product's own position is already written into section 7: the AI answers only from articles the customer wrote and published, it names its sources, and the customer can switch it off. That is a strong argument for the customer carrying it, backed by their indemnity. The alternative — sharing it, or capping our share — is what a buyer in a regulated sector will ask for, and this is the single clause most likely to be negotiated.
Whether data-protection liability sits inside the cap. Many buyers insist a breach sits outside it, or under a higher super-cap. Decide it deliberately rather than meeting it in a redline.

13. Changes to these terms

We may update these terms. If a change materially affects your rights, we will tell you before it takes effect.

[DEFAULT — confirm] 30 days' notice, by email to account owners and by a notice in the product, before a material change takes effect. If you do not accept it, you may cancel before it starts and you will not be charged for anything after that — whether unused prepaid time is also refunded follows the refunds decision in section 4. Changes that are not material take effect when published, and the date at the top changes.

Why 30 days and a free exit: a term that lets one side rewrite the agreement while the other is locked in is the first thing a regulator strikes out, and 30 days matches every other notice period in these terms.

14. Governing law and disputes

[DEFAULT — confirm] These terms are governed by the law of the Republic of South Africa, and the parties submit to the jurisdiction of the Gauteng Division of the High Court, Johannesburg. That is the division for Rosebank, where the company is registered.

A consumer's non-excludable rights, and the data-protection law of the place a visitor actually sits, apply regardless of this clause — because they do, and a clause pretending otherwise is the one that gets struck out.

Why this rather than the alternatives:

South African law, Gauteng Division, Johannesburg. Cheapest to enforce where the entity and its assets actually are, no foreign counsel on retainer, and the honest answer for a South African business selling self-serve. The cost: an EU or UK enterprise buyer will query it in procurement, and it does not stop their own consumer and data-protection law applying to them anyway.
English law, courts of England and Wales. What large international buyers expect and rarely argue with, with a deep body of commercial precedent behind it. The cost is real: enforcing an English judgment against a South African entity means starting again in a South African court, and English counsel is expensive for a business of this size. It buys procurement goodwill and pays for it in every actual dispute.
South African law, with the operator agreeing to the customer's local courts above a stated contract value. A negotiating position rather than a default; only worth writing once there is a deal that needs it.

[CONFIRM] with the reviewer that Rosebank falls in the Johannesburg seat rather than Pretoria — it does on the ordinary division of the Gauteng jurisdiction, but the clause names a court and should not be taken on trust.

⚠️ DECISION NEEDED: how a dispute is actually resolved.

Courts, with a good-faith negotiation step first — 30 days of the two sides trying to settle before either files. Free, standard, and the step alone resolves most of what would otherwise become a claim.
Arbitration — AFSA in South Africa, or a named institution internationally. Private and usually faster, but the arbitrator's fees are real money on a contract this size, and an arbitration clause is one of the terms South Africa's Consumer Protection Act regulates when the other side is a consumer or a small juristic person.
A split: arbitration above a stated contract value, courts below it. Two processes to run, worth it only once there are contracts large enough to justify the first.

The first. It costs nothing, it is enforceable everywhere, and it does not need revisiting until there is a dispute big enough to make arbitration worth paying for.

15. General

Entire agreement. These terms, the Privacy Policy, and any Data Processing Addendum, are the whole agreement between us about the service.
Severability. If a term is unenforceable, the rest stays in force.
No waiver. Not enforcing a term once does not give it up.
Assignment. You may not transfer this agreement without our consent. We may transfer it as part of a merger, acquisition or sale of the business.

16. Contact

Notices under these terms go to:

Learn App (Pty) Ltd, trading as HeyThula, registration number 2020/142526/07.
By post, and for service of legal notices: 173 Oxford Road, Rosebank, 2196, South Africa. [CONFIRM] the postcode — see section 1.
By email: Greg Kockott, greg@hellocrowd.net.

Two things about that address are still open — whether hellocrowd.net is the right domain for this entity at all, and whether a role address such as legal@ should replace a personal one. Both are set out once, in the Privacy Policy under "Contact us", and the same answer should apply to both documents.