What does custom business software cost in South Africa?

There is no useful universal price for custom software

Asking what custom software costs is a bit like asking what a building costs before deciding whether it is a garden office or a distribution centre. Both are buildings, but the work, risk and detail are very different.

The same applies to business software. A focused internal tool for a handful of users is a different project from a workflow application with multiple departments, integrations, reporting, document generation and mobile requirements. A responsible quotation starts with the process and scope, not with a generic market average.

What actually influences cost?

Project scope

The biggest driver is simply how much the system needs to do. A short, well-defined workflow with a few screens is less work than a platform covering quoting, customers, approvals, production, billing and reporting.

Number and type of users

User count matters, but roles often matter more. Ten people doing the same task can be simpler than five people with five different permission sets, dashboards and approval responsibilities.

Workflow complexity

A straight path such as request → review → approve is easier to model than a process with exceptions, rework loops, conditional approvals, escalations, deadlines and different routes for different request types.

Integrations

Connecting to existing systems can be straightforward when they provide a well-documented interface. It can be difficult when data has to move through older software, scheduled file exports or undocumented formats. The integration needs to be investigated before it can be priced sensibly.

Authentication and permissions

A simple internal login is not the same as single sign-on, multi-factor authentication, external customer accounts or detailed role-based permissions. Security requirements should be part of the scope from the start.

Reporting

A few operational totals are different from a configurable reporting environment with filters, exports, historical views and management dashboards. Reporting is often underestimated because the word “report” can mean many things.

Document generation

Quotes, certificates, labels, job cards or PDFs may need exact layouts, numbering, conditional content and downloadable archives. The more production rules a document carries, the more carefully it needs to be specified and tested.

Mobile requirements

A responsive browser interface is often sufficient. Offline use, camera workflows, location features or native mobile applications add a different level of complexity.

Hosting, maintenance and support

The project does not end at launch. Hosting, backups, security updates, monitoring and future changes need an operating model. Some systems need occasional maintenance; others become business-critical and need a more deliberate support arrangement.

Automation and legacy systems

Automating a clean, consistent process is usually easier than automating around years of exceptions. Legacy systems can still be integrated, but the available interfaces and data quality matter.

Three useful project shapes

A small internal tool

This might replace one spreadsheet-based process: capture a request, store records, track status and provide a simple view for the people doing the work. The value is focus. It solves a defined problem without trying to become the company’s entire operating platform.

A substantial workflow application

This typically involves several roles, defined stages, approvals, notifications, dashboards, reporting and perhaps document generation or one or two integrations. Most of the effort is not in making screens. It is in understanding the rules, exceptions and handovers well enough to make the workflow dependable.

A complex business platform

A larger platform may cover several connected functions, external users, multiple integrations, detailed permissions, large datasets, reporting, migration from old systems and ongoing operational requirements. At this scale, discovery, architecture, testing, deployment and support become significant workstreams.

How to make a quote more meaningful

• What process are you trying to improve?
• Who uses it and what does each person need to do?
• What information enters the process, and where does it come from?
• What outputs are required?
• Which approvals or business rules matter?
• Which existing systems need to exchange data?
• What happens when something is missing, rejected or unusual?
• Which reports are actually needed to run the process?

A short screen recording of the current process, a representative spreadsheet, sample documents and a simple workflow sketch can be more useful than a long feature wish list.

Price should follow scope, not the other way around

A budget matters and should be discussed. It helps decide whether to build a focused first version, use an existing product, change the process or phase a larger system. What is less useful is pretending that every “custom app” falls into a standard price band.

If you are still deciding whether custom software is the right route, read custom software vs off-the-shelf software. If the project began as an overloaded workbook, this Excel decision guide may help clarify the problem before you request a quote.