Build & automate
Freelance developer vetting checklist (South Africa)
The cost of a bad developer hire is rarely the fee. It is the lost months, the half-built thing nobody else can finish, and the code you cannot legally use. Most of that is avoidable with a short checklist run before any money changes hands. Here is the version that actually protects you.
Why vetting matters more than the rate
The cheapest quote is regularly the most expensive outcome. A developer who underprices, then abandons the project, leaves you to pay someone else to start over, often from a codebase that was never handed over or documented. The same is true of a developer who built something competent but never assigned you the copyright: under South Africa’s Copyright Act the developer is the default owner of the code they write, so without a signed assignment you can be left paying for software you do not actually own. The rate is a small number next to that.
The step-by-step
Run these in order before you commit the budget. Each one removes a way the hire can go wrong.
Check real, shipped work. Ask to see live products you can open and use, and their code on GitHub, not a PDF portfolio. Then ask what they personally built versus what a 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 the project actually ended, which is the part that matters most.
Lock IP ownership in writing first. Agree, before you pay, that all copyright in the code assigns to you. Because the Copyright Act makes the developer the default owner, a signed written assignment up front is the only thing that puts the result in your hands.
Agree scope, milestones and acceptance. Write down exactly what ‘done’ means for each milestone and how you will sign it off. A clear definition of done is what stops a later disagreement turning into a stalemate.
Require source code and documentation. Make full source plus build-and-run documentation a paid-for deliverable you own, not a favour. Without it you have vendor lock-in the moment the developer is gone.
Ask about open-source and reused code. Require disclosure of any third-party or pre-existing code and its licence. Undisclosed reused code is a compliance problem you inherit, so surface it before it is baked into your product.
Start with a small paid test task. A one-to-three-day paid task shows you real quality and communication in a way no interview can. Pay for it properly and judge the work itself.
Stage the payments with holdbacks. Pay against accepted milestones and hold a final portion until handover. That way, abandonment costs the developer, not you, and keeps the incentive pointed at finishing.
Red flags to walk away from
Any single one of these is a warning. Two or more together is a walk-away.
| Red flag | Why it matters |
|---|---|
| No live work to show | You cannot verify they have actually shipped anything that works |
| Won’t sign an IP assignment | You may not legally own the code you paid for |
| Vague on scope | ’Done’ is undefined, so disputes and scope creep are baked in |
| Won’t 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 | Vendor lock-in: nobody else can maintain or extend the work |
The paid test task
The single best filter is a small, paid test task before the main contract. An interview shows you how someone talks about work; a paid task shows you the work. Scope it to a day or three of real effort, 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. You learn whether they hit the brief, whether the code is clean, and whether they are easy to work with, all for a small fraction of the full budget. Treat it as cheap insurance against an expensive bad hire, not as free labour, and pay it even if you decide not to continue.
Where Zaiq fits
Zaiq is an AI engineering studio in South Africa, and hiring us means skipping the freelance lottery entirely. The IP is yours from day one, there is no abandonment risk because you are engaging a studio, not betting on one person, the price is fixed up front, and the handover is clean: full source code and documentation, built to be picked up and run. We do not sell you hours and hope; we solve the problem and hand you something you own. If you want a build without the vetting gamble, bring us the problem at zaiq.ai/work and we will tell you straight what it takes.
This is general guidance, not legal advice. For your contract, confirm with a South African commercial lawyer.
Related guides
Vet a freelance developer before you hire
Eight checks that separate a real builder from a risky one, before any money changes hands.
Check real, shipped work
Look at live products and their GitHub or code, not a polished PDF portfolio. Ask what they personally built versus what the wider team built, so you know whose work you are actually buying.
Talk to two past clients
Ask about deadlines, communication, and whether the handover was clean. References catch the things a portfolio is built to hide, and two voices are harder to stage than one.
Lock IP ownership in writing first
Agree, before you pay, that all copyright in the code assigns to you. South Africa's Copyright Act makes the developer the default owner otherwise, so a signed assignment is non-negotiable up front.
Agree scope, milestones and acceptance
Write down exactly what 'done' means for each milestone and how you will accept it. A clear definition of done is what stops a scope argument turning into a stand-off later.
Require source code and documentation
Make full source code plus build and run documentation a paid-for deliverable you own, not a favour you hope for. Without it you have vendor lock-in the day the developer walks away.
Ask about open-source and reused code
Require disclosure of any third-party or their own pre-existing code, and its licence. Undisclosed reused code is a compliance landmine you inherit, so surface it before it ends up in your product.
Start with a small paid test task
A one-to-three-day paid task tells you more about quality and communication than any interview. Pay for it properly and judge the real thing, not a rehearsed pitch.
Stage the payments with holdbacks
Pay against accepted milestones and hold a final portion back until handover. Staged payment means abandonment costs the developer, not you, and keeps the incentive pointed at finishing.
Questions people ask
How do I check a freelance developer's work?
Look at real, shipped products you can open and use, and at their actual code on GitHub, not a polished PDF portfolio. Ask specifically what they personally built versus what a team built, since portfolios often show group work. Live work plus a code trail is far harder to fake than a slide deck.
What should I ask a developer's references?
Speak to at least two past clients and ask about deadlines, communication, and whether the handover was clean: did they get the full source code and documentation, and could another developer pick it up. References surface the things a portfolio is built to hide, especially how the project actually ended.
Should I pay a developer upfront?
Not the full amount. Stage payments against accepted milestones and hold a final portion back until handover, so abandonment costs the developer, not you. A small paid test task up front is fair, but paying everything before delivery removes the one lever that keeps the work pointed at finishing.
How do I stop a developer disappearing mid-project?
Stage the payments with holdbacks, agree clear milestones and acceptance, and make full source code and documentation a paid-for deliverable from the start. If money is owed and the code lives in your repository at each milestone, walking away costs the developer more than finishing, which is the point.
What are the red flags when hiring a developer?
No live work to show, refusing to sign an IP assignment, vagueness on scope, declining a small paid test task, dodging references, and no clear source-code handover. Any one is a warning; two or more together is a walk-away. The pattern to watch is reluctance to commit anything to writing up front.
How much should a paid test task cost?
A small fraction of the full project, scoped to a day or three of real work, and paid at a fair rate. The goal is not to save money, it is to see genuine quality and communication before you commit the whole budget. Treat it as cheap insurance against a far more expensive bad hire, not as free labour.