How to choose a software development company in South Africa

Ask six things before you sign: is the price fixed, how often will you see working software, who owns what, what happens if you leave, who answers when it breaks, and what have they built that's still running. A company worth hiring answers all six in writing before you pay a deposit.

This is the list we'd use if we were hiring someone to build software for us. Our own answers are further down, printed, so you can hold us to the same standard. The work itself is described on our web apps and business systems page.

Why do these questions matter more than the portfolio?

A portfolio shows what a company can make look good. It doesn't show how they behave in month four, when the budget is half spent and a feature turns out to be harder than expected. Most software projects that go badly go wrong on the terms: an hourly bill with no ceiling, a demo that keeps getting postponed, a contract that leaves the code and your data with the developer.

If you've been through that once, you already know which questions you wish you'd asked. Here they are.

1. Is the price fixed, or am I paying by the hour?

There are two common ways to price software.

Hourly (sometimes called "time and materials"). You pay for the hours worked. The estimate at the start is a guess, and you carry the risk if it's wrong. This suits work where nobody can say up front what the finished thing looks like.

Fixed price for agreed work. The company agrees what it will build and what it costs, in writing. If the work takes longer than they thought, that's their problem. If you change what you want, the price changes, and that change should be quoted in writing before anyone starts on it.

Ask them: "If this takes twice as long as you think, who pays?" A clear answer is fine either way. If they can't give one, you're the one carrying the risk.

A weak answer sounds like "we'll give you a ballpark and refine it as we go". That's hourly billing described politely.

2. How often will I see working software?

You should be able to click through the real thing, with your own data, every two weeks or so. Screenshots and slide decks don't count. Neither does a "demo" that someone else drives while you watch.

Regular working versions matter for two reasons. You catch misunderstandings while they're cheap to fix. And you can tell whether the project is moving. A company that goes quiet for three months and then shows you something is asking you to trust them for three months.

Ask them: "When will I first be able to log in and try it myself?" If the answer is "at the end", keep looking.

3. Who owns the code, the data and the domain?

These are three different things, and contracts often treat them differently.

• Your data (customer records, bookings, invoices, whatever the system holds) should always be yours, and you should be able to export it without asking permission. If a company hesitates on this one, walk away.
• The domain (your web address) should be registered in your name, not the developer's.
• The code varies. Some companies sign it over to you. Others keep the code and give you a licence to use the software while you're a client. We license by default, because it keeps the build price down, and quote a handover when a client needs to own the code. Neither model is wrong. What's wrong is not knowing which one you've agreed to until you try to leave.

Ask them to put the ownership terms in the quote itself, not in a document you'll only see after paying. We've written a longer piece on what you actually own if you leave a website company.

4. What happens if I leave?

Every relationship ends eventually, and the end is where hidden terms show up. Ask:

• How much notice do I give?
• What do I get on the way out, and in what format?
• Is there a fee to hand over?
• Does anything stop working on the day I leave?

A company confident in its work is relaxed about this question. One that makes leaving hard is counting on the move being too painful to bother with.

5. Who answers when something breaks?

Get a named response time, in writing. "We're very responsive" means nothing. "We reply within one working day" can be checked.

Also ask who you'll speak to. At some agencies the person who sold you the project disappears after the deposit, and support goes to a ticket queue staffed by people who've never seen your system. Ask whether the people building it will be the people fixing it.

If your current developer has stopped replying, we've written up how to move to someone else without losing your site or data.

6. What have you built that's still running?

Ask for live systems you can open, not mockups. Then ask which of those clients are still with them. A company whose clients leave after a year is telling you something.

If you can, speak to one of those clients. Ask them one question: "When something went wrong, what happened next?"

What do weak answers usually mean?

What you hear	What it usually means
"We'll give you a ballpark and refine it"	Hourly billing with no ceiling
"You'll see it at the end"	No way to catch problems early
"We handle the domain for you"	The domain may be in their name
"We'll send the contract after the deposit"	The terms favour them
"We're very responsive"	No response time they'll commit to
Only mockups in the portfolio	Few finished projects, or none still running

Our answers, printed

Here's how we'd answer our own list. If any of it doesn't suit you, better to know now.

Question	Our answer
Fixed or hourly?	Fixed. After a 20-minute call we send a written quote within two working days. The price only changes if the agreed work changes.
How often will I see it?	Working pages on a private link from week one, then working software every two weeks. You test with real data early.
Who owns what?	Your data is yours and you can export it any time. For websites, the domain is registered in your name. By default we keep the code, licensed to you while you're subscribed. For custom software, owning it outright can be quoted.
What if I leave?	You can export your data whenever you like. For websites, you give 30 days' notice and get a static copy of the site's pages, which any host can serve.
Who answers?	We reply within one working day.
What's still running?	Our portfolio lists live client sites and systems. One example: the Desmed practice app replaced four separate tools the practice was paying for.

Our prices are published: simple systems from R50 000 to R120 000, business systems from R120 000 to R250 000, and platforms from R250 000 up. There's more detail on what moves a project between those bands in how much custom software costs in South Africa.

When are we the wrong choice?

Some buyers are better served elsewhere, and it saves everyone time to say so.

• You want developers billed by the hour, working through your own team's task list. That's a staffing arrangement. We quote fixed prices for agreed work.
• Off-the-shelf software already does 90% of the job. Pay for the subscription and live with the missing 10%. Custom software makes sense when that missing part is the part your business depends on.
• Your budget is well under R50 000. A good spreadsheet, a form tool or an existing app will do more for you than a rushed custom build.

What should I do before the first call?

Write down the one task that costs your business the most time each week, who does it, and what they use now. That's usually where a build should start, and it makes any company's quote more accurate.

When you're ready, read what we build on the web apps and business systems page, then get an estimate or WhatsApp us on +27 73 453 8352. We'll tell you on the call if we're not the right fit.