What Custom Software Actually Costs in South Africa

Nobody publishes software prices, which leaves buyers guessing and gives vendors room to quote whatever the room will bear. This is our attempt at a straight answer: what actually drives the number, what the ranges genuinely look like in the South African market, and which quoting behaviours signal that a project is going to go badly.

Why nobody gives you a price on the phone

Software cost is driven almost entirely by scope, and scope is not knowable from a two-sentence description. "A booking system" could be a form that emails you, or a multi-tenant platform with payments, capacity rules, refunds and accounting integration. Those differ by a factor of thirty. Any developer who quotes before understanding which one you mean is either guessing high to protect themselves or guessing low to win the work and repricing later.

The five things that actually move the number

• User roles. Each distinct type of user — admin, staff, customer, supplier — is effectively a separate interface with its own permissions and its own testing surface. Going from one role to four does not add 3 units of work, it roughly triples it.
• Integrations. Every external system you connect to adds authentication, error handling, edge cases and a dependency you do not control. A single integration with a well-documented API is manageable. Four integrations with legacy systems is often the bulk of a project.
• Data migration. Moving history out of an old system is consistently underestimated. Real-world data is messy, inconsistent, and full of records that break the rules the new system enforces. Cleaning it is unglamorous work that has to happen.
• Compliance and audit requirements. Immutable audit logs, data residency, role separation and evidence export are architectural, not cosmetic. They are far cheaper designed in than retrofitted.
• Non-functional requirements. "Must handle 500 concurrent users", "must stay up during month-end", "must work offline" each imply architecture that costs more than the naive version.

Realistic ranges

With the caveat that scope dominates everything: a focused internal tool that automates one process for one type of user typically lands in the tens of thousands of rand. A departmental system with several roles, a handful of integrations and proper reporting usually runs into the low-to-mid hundreds of thousands. A customer-facing platform or mobile app with payments, multiple user types and real-time features generally starts in the hundreds of thousands and climbs from there.

Rates vary meaningfully by where the supplier sits. A Sandton or Cape Town agency carries office and sales overhead that a remote-first team does not, and that difference shows up in the hourly rate without any corresponding difference in engineering quality.

Quoting practices that should worry you

• A fixed price given before any written specification exists. The specification is where the cost is discovered. A number that precedes it is a sales tactic.
• A quote that is dramatically below the others. It usually means the scope was misread, and the gap gets recovered through change requests later.
• No line item for testing, deployment, documentation or handover. These are not optional; excluding them makes a quote look competitive while quietly moving work into your column.
• Ongoing costs left undiscussed. Hosting, third-party services, app store fees and maintenance are real. A build price without a running-cost estimate is half a picture.
• IP ownership left vague. You should own the code you paid for, in your own repository. Get it in writing.

The cheapest way to control cost

Pay for a discovery phase first, as a small standalone engagement. You get a written specification, a data model and a fixed-price estimate — and you own that document. You can then take it to three suppliers and get genuinely comparable quotes, instead of three vendors pricing three different imagined projects. It is the single highest-return few thousand rand you can spend on a software project.