CRM & automation
How do you choose a custom CRM developer in South Africa?
Most of the risk in a custom CRM sits in the contract and the handover, not the code. A working system is only half of what you're paying for. The other half is being free to keep running it without the developer who built it.
This guide covers what to prepare before you hire a CRM developer, the questions to ask, who owns the code, and how to compare quotes. It assumes you've decided to build. If you haven't, read about building versus buying a custom CRM first, including when building is the wrong call. And if your customers still live in a spreadsheet, start with whether you've outgrown Excel.
What should you have ready before you talk to a CRM developer?
A one-page brief in your own words. It makes quotes comparable, and it shows you quickly which developers listen.
Describe the process the CRM has to run, exceptions included, and who will use it. List the systems it must connect to, such as accounting, email, WhatsApp and the website form. Say where your customer data lives today and how tidy it is. Then name, in one sentence, the problem that started all this.
A pest control company in Gqeberha, for example, might write that customers have several sites, each site has its own treatment schedule and contract, technicians work from their phones, and invoices go to Sage. That's enough for a good developer to start asking sharp questions. It's also enough for you to notice which developers don't ask any.
What questions should you ask a custom CRM developer?
Ask questions that make a developer show how they work, not only what they've built. Put these to every candidate.
- What do you need to see before you can quote? Listen for a request to walk through your process, some sample records and your systems before any price.
- Can we see something you've built, working? Slides prove nothing.
- Who will do the work? Get names, ask whether anything goes to a subcontractor, and find out who you phone when something breaks.
- What will you build first? The workflow that hurts most, in front of real users, with the rest phased.
- How will you move our existing data? Look for a plan to clean it, test the move on a copy, and agree what gets left behind.
- How will it connect to our other systems? Ideally through the published APIs of the tools you use, not by copying data off screens or sharing one login. Our workflow automation page lists the kinds of systems these builds usually connect to.
- What happens after launch? Ask what support covers, how changes are quoted and what it all costs each month.
- How will the system handle POPIA requests? People can ask what you hold about them, and ask you to correct or delete it where it's inaccurate, out of date or no longer allowed to be kept (sections 23 and 24 of POPIA). Ask the developer to show you how the CRM would find, export, correct and delete one person's records.
- If we part ways, what do we walk away with? The answer should be a list, and the list belongs in the contract.
The last question is the one buyers forget, so the next two sections deal with it.
Who owns the code when you pay someone to build your CRM?
Don't assume that paying for the build makes the code yours. Under the Copyright Act 98 of 1978, the author of a computer program is "the person who exercised control over the making of the computer program". Copyright belongs to the author in the first place, and on a commissioned build, who that was isn't always obvious. It's not something you want to argue about after a falling-out.
Two rules in the Act that give copyright to someone other than the author won't settle it for you either. The rule for commissioned work names photographs, portraits, gravures, films and sound recordings, not computer programs. The rule for employees covers work made under a contract of service, and an outside developer isn't your employee.
So put it in writing. Section 22(3) says an assignment of copyright has no effect unless it's in writing and signed by or on behalf of the person assigning it. Section 22(5) allows copyright in a future work to be assigned, so a contract signed at the start can cover code not yet written.
The clause should settle three things. First, what's assigned to you: the code written for your project, the database design and the documentation. Second, what the developer keeps, such as their own reusable components, and your licence to use those for as long as you run the system. Third, the outside pieces, such as open-source libraries and paid services, which carry licences of their own that your contract can't change.
This is a general outline of the Act, not legal advice. Ask an attorney to draft the clause, or to check the one you're given.
What should a CRM developer hand over, and what should be in your name?
Set the accounts up in your company's name from day one, with the developer added as a user. If you part ways, there's then nothing to hand over, only access to remove.
That means the hosting or cloud account, the domain, the code repository, and the database with its backups. It also means any email or SMS sending service, the WhatsApp Business account and the keys for every paid service. All of it should be billed to your company and recoverable without the developer's help.
The handover itself is more than a folder of documents. Ask for a plain description of every table and field, and a list of every outside service the system depends on, who pays for it and where its key is kept. Ask for an export of all your data in a standard format such as CSV, and open it yourself. And watch a restore from backup, because you only know a backup works once someone has restored it.
Then have a second developer read the notes and say whether they could take over. If they can't, the handover isn't finished. Repeat the check after every big change.
How do you compare quotes from CRM developers?
Make every developer answer the same brief in the same shape, then compare what's included rather than the total.
Ask for each quote in four parts. First, the once-off build, phase by phase. Then the monthly running costs, with hosting, paid services and support shown separately. Then anything billed in US dollars, which moves with the exchange rate. Last, what's excluded, such as data migration, training and changes after launch. A quote that leaves out migration and support can look cheap until you add them back. Our custom CRM page explains why the rand-dollar rate matters on software bills.
If cost is the worry, ask for a first phase that solves one problem and stands on its own. It limits what you spend before you've seen how the developer works, and you keep a working system if you stop there.
Does a CRM developer need to be near you?
No. CRM work can be done remotely, and a developer in another province can build for you as well as one down the road. What matters more is that they're reachable in your working hours, quote in rand, and understand POPIA, because your customer records are what they'll be handling.
Meet before you sign, by video if not in person, and meet the person who will do the building, not only the one selling it. If the system will be hosted outside South Africa, ask them to explain where the data will live and on what basis it may go there.
What are the warning signs when hiring a CRM developer?
Slow down, or walk away, if a developer:
- commits to a firm price for the whole build before seeing how your business works
- wants the hosting and the code to stay in their own accounts
- can't, or won't, say who owns the code
- never suggests an off-the-shelf product, even for part of the job
- builds on a platform only they can work on
- writes a scope that says "CRM system" and very little else
- talks about features before asking about your customers
How does Cognexa approach a custom CRM build?
Cognexa builds custom CRMs and integrates existing ones, from Centurion, for businesses across South Africa. If an off-the-shelf CRM would serve you better, as it would most South African businesses, we'll tell you before anything is built. Often the sensible first step is to keep the CRM you have and connect your other channels to it, which is separate work from a build. One example is automating follow-up after a website enquiry.
When a build is the right call, we design it around your existing process and test it against real cases before it touches a customer. If an AI agent is part of the build, there's a written list, agreed with you before launch, of everything it may do without a person. The people who scope your project are the people who build it, and you deal with them directly from the first call to go-live.
We expect to be judged on the same nine questions as every other developer you talk to.
What should be in the contract before you sign?
Lay the contract beside the written answers you collected and look for gaps: an ownership clause that isn't a signed assignment, an account left in the developer's name, a handover with no restore test, or support and changes with no price. If you find one, raise it now, while you still have a choice of developer. Then have an attorney read the ownership clause before anyone signs it.