“How much does custom software cost?” is a fair question with an unsatisfying answer: it depends on what you are building. Two systems that sound similar when described in a sentence can be very different amounts of work. One serves five staff members with a simple workflow. The other serves hundreds of users with permissions, integrations and reporting.
We have not published a table of rand figures, because any single number would mislead. This guide explains what shapes the cost of custom software development in South Africa and how to prepare for an honest conversation about it.
Why there is no standard price
Custom software is built around a specific business process. Unlike a product with a published price list, the work depends on your rules, your people and your existing systems. That is the point of building it, and it is also why quotes differ so widely.
The most useful early step is a short scoping process in which the workflow, users and integrations are understood before any estimate is given. A quote produced without it is a guess.
What drives the cost
Custom business system
What it does
- Workflows
- Reporting
- Notifications
Who uses it
- Users
- Permissions
What it connects to
- Integrations
What it runs on
- Data
- Infrastructure
Users, roles and permissions
A system for one team is simpler than one where staff, managers, customers and suppliers all see different things. Every additional role needs design, rules and testing.
Workflows and business rules
The more steps, exceptions, conditions and approvals in a process, the more logic has to be designed, built and tested. A simple linear flow is far less work than one with branches and special cases.
Dashboards and reporting
A basic list of records is straightforward. Filtered views, charts, exports and management-level reporting require extra design and careful handling of the underlying data.
Integrations and APIs
Connecting to accounting packages, CRMs, payment providers or other internal systems depends on the quality of the other system’s interface. Poor documentation or limited access adds effort. Our systems integrations page describes the kind of work involved.
Document and PDF generation
Quotes, invoices, certificates and reports that must match a specific layout take real design and testing time, especially when the content varies.
Notifications
Emails or messages triggered by events, with the right wording and the right recipients, are small individually but add up across a system.
Data complexity and inventory
Stock levels, pricing rules, product variants, units of measure and anything that must stay accurate across transactions make a system more demanding to build and test.
Importing existing information
Getting data out of spreadsheets or an older system and into the new one is often underestimated. Messy, inconsistent or incomplete source data takes time to clean and map.
Mobile requirements
A system that must work well on phones or tablets in the field needs more design and testing than one used only at a desk. Offline use adds considerably more.
Authentication and security
Secure logins, password handling, access control and protection of personal information are not optional. If the system holds personal data, it also has to be designed with your POPIA obligations in mind, which your own legal adviser should confirm.
Testing and quality
Testing is a large part of building reliable software, not an optional extra. Systems that people depend on every day need to be tested against real scenarios before they go live.
Hosting and infrastructure
Where the system runs, how it is backed up and how it is monitored all have recurring costs and setup work, and the right choices depend on how critical the system is.
Support and ongoing development
A launched system is never quite finished. Fixes, changes in your business and new requirements are normal. Budget for support and further development rather than treating launch day as the end.
MVP versus a complete system
A minimum viable product (MVP) is a first version that does the most important job well, and nothing more. A complete system tries to cover everything from day one.
Starting with an MVP has real advantages: your team starts getting value sooner, you learn what actually matters from real use, and you avoid paying for features that turn out to be unnecessary. The trade-off is that you accept some manual work for a while, and you need to be disciplined about what “first” means.
Phased development
Splitting a larger system into phases lets you spread the investment and adjust as you learn. A typical approach is to build the core workflow first, then add reporting, then integrations, then portals or mobile access. Each phase should deliver something usable. The key is to design the foundation with later phases in mind, so you are not rebuilding it each time.
- 01
Discovery
Understand the workflow, users and integrations
- 02
MVP
The most important job, done well
- 03
Phase 2
Reporting and refinements, shaped by real use
- 04
Integrations
Connect the other systems involved
- 05
Ongoing development
Support, fixes and new requirements
Phasing can reduce the initial scope and help validate priorities before everything is built.
When custom software probably is NOT the right answer
Custom software is not always the answer, and any provider worth working with will say so. Off-the-shelf software is usually the better choice when:
- An existing product covers most of your requirement and you can live with the rest.
- The process is standard for your industry and well served by established tools.
- The process is still changing and you are not yet sure what it should be.
- The volume is too low to justify the build and ongoing support.
- Connecting the tools you already have would solve the actual problem.
- The real problem is an unclear or broken process that software will not fix.
Our guide to business process automation sets out how to decide between improving the process, using existing software, integrating tools and building something custom.
What to prepare before asking for a quote
- A plain description of the process today, step by step, including the workarounds.
- Who uses it, and what each type of user needs to see and do.
- The tools and spreadsheets currently involved.
- Where it breaks down, and what that costs you in time or errors.
- Which systems it needs to connect to.
- What existing data would need to be moved across.
- Whether people need to use it on phones or in the field.
- What you would want in a first version versus later.
You do not need a technical specification. A clear description of the problem and how the business works is enough to start. Our web applications and business systems service begins with that conversation.
Frequently asked questions
Is custom software worth the investment?
When it replaces a process that costs the business real time, errors or lost opportunities every week, often yes. When an existing tool would do the job reasonably well, usually no. The deciding factor is how specific and how important the process is to your business.
Who owns the code?
This should be agreed in writing before work starts. Ask who owns the source code and the finished system, what you receive on completion, and what happens if you want another provider to maintain it later.
Can it be built in stages?
Yes, and for most projects it is a sensible approach. Build the most important part first, use it, and extend it based on what you learn. It spreads the investment and reduces the risk of building the wrong thing.
How long does it take?
It depends on scope. A focused first release can be much quicker than a complete system. A proposal should explain the schedule and what it depends on, including how quickly your team can answer questions and review progress.
What happens after launch?
Real use always shows what needs refining. Plan for support, fixes and further development after launch, and agree how that will work before you commit.