Build & automate
Vet a Freelance Developer in South Africa: 8-Step Checklist
Before you vet a freelance developer, know what you are protecting yourself from. The cost of a bad hire is rarely the fee. It is the lost months, the half-built product nobody else can finish, and code you may not have the right to use. Most of that is avoidable with a short checklist, run before any money changes hands. Here is the version that protects a South African business.
Why you should vet a freelance developer before comparing rates
The cheapest quote often becomes the most expensive outcome. A developer who underprices and then abandons the project leaves you paying someone else to start again, often from code that was never handed over or documented. Ownership is the other trap. Under the Copyright Act, the author of a computer program is the person who exercised control over its making, and the author is the first owner of the copyright unless the work was made by an employee. With a freelancer that can be the developer, and an assignment to you only has effect if it is in writing and signed. The hourly rate is a small number next to that.
The 8-step checklist
Run these in order before you commit the budget. Each one closes off a way the hire can go wrong.
1. Check real, shipped work. Ask to see live products you can open and use, and the code behind them. Then ask what they personally built and what a team built, so you know whose work you are buying.
2. Talk to two past clients. Ask about deadlines, communication and whether the handover was clean. They will tell you how the project actually ended, which is the part that matters most.
3. Get the IP assignment in writing first. Agree, before you pay, that all copyright in the code is assigned to you. Section 22(3) of the Copyright Act says an assignment has no effect unless it is in writing and signed by or on behalf of the person assigning it.
4. Agree scope, milestones and acceptance. Write down what done means for each milestone and how you will sign it off. A clear definition of done stops a disagreement turning into a stalemate.
5. Require source code and documentation. Make full source code plus build and run instructions a deliverable you own, handed over at each milestone, not a favour at the end.
6. Ask about open-source and reused code. Require disclosure of any third-party or pre-existing code and its licence. Open-source licences, listed by the Open Source Initiative, come with conditions, and you inherit them once the code is in your product.
7. Start with a small paid test task. A paid task of one to three days shows real quality and communication in a way no interview can.
8. Stage the payments with holdbacks. Pay against accepted milestones and hold a final portion until handover, so abandonment costs the developer, not you.
Freelance developer red flags
Any one of these is a warning. Two or more together is a reason to walk away.
| Red flag | Why it matters |
|---|---|
| No live work to show | You cannot check that they have shipped anything that works |
| Will not sign an IP assignment | You may not own the code you paid for |
| Vague on scope | Done is undefined, so disputes and scope creep are built in |
| Will not do a paid test task | You only see real quality after the full budget is committed |
| Dodges references | The track record they will not let you check is the one to worry about |
| No source-code handover | Nobody else can maintain or extend the work |
The paid test task
The best single filter is a small, paid test task before the main contract. An interview shows how someone talks about work; a paid task shows the work. Scope it to one to three days, pay a fair rate, and ask for the same things the full project needs, in miniature: working code in a repository you can see, a short note on how to run it, and clear communication along the way.
For example, a Stellenbosch wine farm hiring a freelancer to build an online booking system could first pay for a three-day task: one booking form that saves to a database and sends a confirmation email. After three days the owner knows whether the developer writes clean code, meets a deadline and explains problems clearly, for a small fraction of the full budget.
If the developer will see customer data
If the developer works with personal information, such as a customer database, they are processing it on your behalf, and POPIA applies. Section 20 requires anyone processing personal information for you to keep it confidential. Section 21 requires a written contract that obliges them to keep it secure, and it requires them to tell you immediately if they have reason to believe someone accessed it without authorisation. Give them test data where you can, and only the access they need.
Studio or freelancer?
The same checks apply to a studio, although a company is less likely to vanish than one person. Ask any provider for a fixed price against a written scope, the IP assignment and the source-code handover in the contract. As one reference point, Zaiq’s published prices start from R8,000 for a focused build and state that you own the result.
For the contract clauses in detail, see hiring a developer in South Africa: contracts and IP. This is general guidance, not legal advice. For your contract, speak to a South African commercial or IP lawyer.
Vet a freelance developer before you hire
Eight checks that separate a reliable builder from a risky one, before any money changes hands.
Check real, shipped work
Look at live products and their code, not a polished PDF portfolio. Ask what they personally built and what a wider team built, so you know whose work you are buying.
Talk to two past clients
Ask about deadlines, communication and whether the handover was clean. Two references are harder to stage than one, and they tell you how projects actually end.
Get the IP assignment in writing first
Agree before you pay that all copyright in the code is assigned to you. Under the Copyright Act an assignment only has effect if it is in writing and signed by the developer.
Agree scope, milestones and acceptance
Write down what done means for each milestone and how you will sign it off. A clear definition of done stops a disagreement turning into a stand-off.
Require source code and documentation
Make full source code plus build and run instructions a deliverable you own, handed over at each milestone. Without it you are locked in the day the developer walks away.
Ask about open-source and reused code
Require disclosure of any third-party or pre-existing code and its licence, so nothing with conditions you never agreed to ends up in your product.
Start with a small paid test task
A paid task of one to three days shows you real quality and communication in a way no interview can. Pay a fair rate and judge the work itself.
Stage the payments with holdbacks
Pay against accepted milestones and hold a final portion back until handover, so abandonment costs the developer, not you.
Questions people ask
How do I check a freelance developer's work?
Look at real products you can open and use, and ask to see the code behind them, not a polished PDF portfolio. Ask specifically what they personally built and what a team built, because portfolios often show group work. Live products plus a code trail are much harder to fake than slides, and they show you the quality you will actually get.
Should I pay a developer upfront?
Not the full amount. Pay for a small test task upfront if you like, then stage payments against accepted milestones and hold a final portion back until the source code and documentation are handed over. Paying everything before delivery removes the one lever that keeps the work pointed at finishing, and it leaves you with nothing if the developer disappears.
How do I stop a developer disappearing mid-project?
Stage the payments with holdbacks, agree clear milestones and acceptance, and require the code in a repository you control at every milestone. If money is still owed and you already hold the code, walking away costs the developer more than finishing. A signed IP assignment means another developer can pick up the work legally.
What are the red flags when hiring a developer?
No live work to show, refusing to sign an IP assignment, vague answers on scope, declining a small paid test task, dodging references and no plan for handing over source code. Any one is a warning; two or more together is a reason to walk away. The pattern to watch is reluctance to put anything in writing before work starts.
Who owns the code a freelancer writes for me?
Do not leave it to chance. Under the Copyright Act, the author of a computer program is the person who exercised control over its making, and the author is the first owner unless the work was made by an employee in the course of employment. With a freelancer that can be the developer, so get a written, signed assignment.
How much should a paid test task cost?
A small fraction of the whole project, scoped to one to three days of real work and paid at a fair rate. The goal is not to save money but to see genuine quality and communication before you commit the full budget. Pay it even if you decide not to continue, and treat it as cheap insurance against an expensive bad hire.
Sources
- South African Government, Copyright Act 98 of 1978
- South African Government, Copyright Amendment Act 125 of 1992 (computer programs)
- South African Government, Copyright Amendment Act 56 of 1980 (ownership, section 21)
- South African Government, Protection of Personal Information Act 4 of 2013
- Open Source Initiative, approved licences
- Zaiq, published pricing
Checked September 2026. Prices and features change, so confirm on the official site before you buy.