Beta vs pilot vs POC — and why the label matters less than the terms
Vendors use the labels loosely, and nothing turns on them legally. What matters is what the document actually regulates: who is testing, what data they load, what counts as success, and whether anyone is paying. The rough market pattern looks like this:
| Stage | Audience | Data | Success criteria | Fee |
|---|---|---|---|---|
| Proof of concept (POC) | Internal team or a single friendly stakeholder | Synthetic or dummy data only | Technical feasibility — can it work at all | Free or cost-recovery |
| Beta | A wider group of external testers (open or closed) | Test accounts; production data is the exception and needs POPIA grounding | Stability, bug discovery, usability feedback | Almost always free |
| Pilot | One or a few real customers — named users, defined environment | Often real business data, so operator terms and security obligations become mandatory | Pre-agreed success criteria tied to a conversion decision | Free, nominal or discounted — charging changes the legal posture |
A court will read the terms, not the heading. Call it a “pilot” while granting open-ended access to production data with no end date and no disclaimers, and you have written a free production licence with full exposure. The eight clauses below are what give the label its intended legal effect.
The eight clauses that matter
Pre-release status + no-reliance acknowledgement
An express statement that the software is pre-general-availability, may contain defects, may change or be withdrawn, and must not be relied on for production or business-critical use. This acknowledgement is the foundation every disclaimer downstream rests on.
Scope, duration + named environment and users
Which modules, which environment (sandbox, dedicated tenant, on-premise test server), which named users, and a hard end date. Open-ended access for "whoever needs it" is how pilots drift into production.
Data handling — synthetic vs production data
State whether the tester may load real data. If real personal information enters the test system, section 21 POPIA operator terms and section 19 security safeguards apply in full — pre-release status earns no exemption. Require deletion or return of all customer data at the end of the test.
Feedback licence
A broad, perpetual, irrevocable, royalty-free licence for the vendor to use all feedback, suggestions and feature ideas — plus an explicit acknowledgement that the tester acquires no IP claim over features built from that feedback. Without this, an enthusiastic pilot customer can contaminate your roadmap.
Disclaimers + liability floor
In a pure B2B test, SA law lets you disclaim warranties aggressively and cap liability at a nominal figure or exclude it. Where consumers participate (a public consumer-app beta), CPA sections 48 and 51 limit how far disclaimers and indemnities can go — draft to the audience, not the template.
Support expectations
Best-efforts support through a named channel, no SLA — or, for an enterprise pilot, a thin pilot SLA (business-hours response, no credits). Never let the production SLA apply by silence or by reference to standard terms.
Success criteria + conversion mechanics
Pre-agree what "success" means and what happens next: production pricing and terms attached as an annexure, or at minimum an agreed term sheet. A pilot that ends without a conversion path ends in renegotiation from zero — usually on the customer's paper.
Termination + de-installation and data return
Either party may terminate on short notice; access is cut off at expiry; the vendor de-installs or disables the software; customer data is returned or deleted with confirmation. The exit must be as clean as the entry.
The pilot-drift problem
The most expensive failure mode in pre-GA testing is not a defect — it is drift. A three-month pilot quietly becomes month nine; the customer’s team has moved real workflows onto the system; nobody has signed anything since the pilot agreement, which expired two quarters ago. The vendor is now running production infrastructure for free, carrying production-grade expectations, while the only document that ever existed disclaims production use.
The drafting answer is structural, not aspirational. Set a hard end date and make expiry automatic: pre-GA, auto-expiry beats auto-renewal every time, because the inertia should force a conversion conversation rather than silently extending free access. Pair the end date with technical enforcement — access that is actually switched off at expiry — so the contract and the system agree with each other.
If use does continue past expiry, the legal position is unattractive for everyone. At best, a court implies a contract from conduct — on terms nobody can state with confidence, and quite possibly without the liability cap and disclaimers the vendor relied on. At worst, there are no governing terms at all. The agreement should say expressly that continued use after expiry is unauthorised unless and until production terms are signed, and that the pilot terms (especially liability and data clauses) survive any holdover in the interim — with the signed production SaaS agreement as the only sanctioned destination.
Paid pilots
Charging for a pilot — even nominally — changes its legal and commercial posture. On the legal side, payment strengthens the CPA “supplier” analysis: where the customer is a natural person or a juristic person below the asset/turnover threshold, supplying software for consideration in the ordinary course of business pulls the relationship squarely into the Act, with its implied quality standards and limits on disclaimers. A free B2B test sits much further from that perimeter. The price tag, in other words, buys the customer statutory expectations the agreement must then manage.
Commercially, the trade usually favours charging anyway. A paid pilot goes through procurement, acquires a budget owner, and converts at a far higher rate than a free trial that nobody inside the customer is accountable for — payment is proof of intent. The clean structure is a modest pilot fee, expressly framed as a fee for a pre-release evaluation (not a warranty of production quality), credited against the first production invoice on conversion. That keeps the no-reliance architecture intact while giving the pilot the procurement gravity that makes the conversion clause worth drafting.
Frequently asked
Do we need a contract for a free beta?
Yes — a free beta is when you need a contract most. Because no money changes hands, there is no commercial document forcing the parties to define the relationship, yet the vendor is exposed on every front: defective pre-release software causing loss, real personal information in a test system, and testers claiming rights over feedback-driven features. The beta agreement is what converts "use at your own risk" from a hope into an enforceable term.
Can we disclaim everything in a beta?
In a business-to-business beta, largely yes — SA law gives commercial parties wide freedom to exclude warranties and cap or exclude liability for pre-release software, provided the clauses are clearly drafted and not against public policy (you cannot exclude liability for fraud, and gross-negligence exclusions face scrutiny). Consumer-facing betas are different: where the CPA applies, section 48 prohibits unfair, unreasonable or unjust terms and section 51 voids certain exclusions outright, so blanket "no liability whatsoever" wording can fail exactly when you need it.
Who owns feedback and feature ideas from testers?
Whatever the agreement says — which is why it must say something. The default position is murky: a tester who proposes a detailed feature design arguably owns copyright in that expression, and an implied licence to use it is narrow and contestable. The standard fix is a perpetual, irrevocable, royalty-free feedback licence plus an express acknowledgement that the vendor may build, own and commercialise resulting features without payment or attribution.
Can testers load real personal information into the beta?
Only with proper POPIA grounding — and even then it is usually the wrong choice. If real personal information enters the test system, the vendor processes it as an operator, which triggers a written section 21 operator agreement and full section 19 security safeguards; "it's only a test" is not a recognised exemption. The better practice for most betas is synthetic or masked data, with production data reserved for late-stage pilots under proper operator terms.
What happens when the pilot ends but the customer keeps using the software?
Legally, something messy. Continued use past expiry creates either an implied contract on uncertain terms or, worse, use with no contractual terms at all — meaning your disclaimers, liability cap and feedback licence may no longer apply while the customer runs your software in production for free. The agreement should state that access terminates automatically at expiry and that any continued use happens only under signed production terms.
Is an NDA enough, or do we need a separate beta agreement?
An NDA only protects confidentiality — it says nothing about licence scope, disclaimers, liability, data handling, feedback ownership or what happens at the end. A beta or pilot agreement covers all of that and should incorporate confidentiality terms within it, so for most pre-release programmes one well-drafted beta agreement replaces the NDA rather than sitting alongside it.
How do we convert a pilot into a production contract?
Decide the mechanics before the pilot starts, not after the customer has leverage. The strongest structure attaches the production agreement (or pricing schedule) to the pilot agreement as an annexure that activates on a conversion notice; the lighter alternative is an agreed term sheet fixing price, term and key commercial points. Either way, pre-agreed success criteria give both sides an objective trigger for the conversion conversation.
What does a beta or pilot agreement cost in SA?
From R7,500 for a bespoke beta or pilot agreement drafted to your product, audience and data profile. Where real personal information will flow through the test, add a section 21 POPIA operator addendum; where the pilot converts to a subscription, drafting the pilot together with the production SaaS agreement is usually more cost-effective than doing them separately.