Every agency that publishes “from R50,000” knows the figure is close to meaningless. It is the smallest job they have ever done, and your job is probably not that job. You find out the real number after the discovery call — the same call you would have had anyway, except now you have anchored on a figure that was never yours.
So here is the useful version instead: the seven things that actually decide what a build costs.
- 1. How many processes it replaces
- One workflow — quoting, say, or job scheduling — is a small, fast build. A system that replaces quoting and scheduling and invoicing and reporting is four builds that all have to agree with each other. This is the single biggest driver, and the one most within your control.
- 2. How many systems it has to talk to
- A tool that stands alone is straightforward. A tool that has to sync with your accounting package, pull from a supplier feed and push to a courier API inherits the quirks of all three. Integrations are where estimates most often move, because the other system’s behaviour is not ours to control.
- 3. How many kinds of user it has
- One internal team on one screen is simple. Admin staff, field staff on phones, managers wanting reports and clients logging into a portal is four interfaces with four permission sets. Each user type adds design, build and testing.
- 4. How much of the process is actually decided
- If your team already agrees on how the process should work, we build it. If three people describe it three different ways — common, and completely normal — part of the work is settling that first. Knowing your own process well is the cheapest thing you can bring to a project.
- 5. What happens to the data you already have
- Starting clean is cheap. Migrating fifteen years of records out of spreadsheets, or out of a system nobody has admin access to any more, is its own small project. Messy historical data costs more to move than most people expect.
- 6. Whether anything is regulated or sensitive
- Handling personal information under POPIA, payment data, or anything needing an audit trail adds access control, logging and testing that a purely internal tool does not need. Worth it, but it is real work.
- 7. What happens after launch
- Software is not a one-off purchase. Hosting, backups, updates and support are an ongoing line item, and an honest quote states it separately rather than burying it. Ours runs month-to-month with no lock-in.
How long it takes, which is the other half of the question
Time and cost track each other closely on bespoke work, and timelines we can be concrete about:
- 4–8 weeks for a focused internal tool or a single automated workflow.
- 2–4 months for a full custom platform, delivered in milestones so you are using working software early rather than waiting for one reveal at the end.
If a quote you are comparing does not break the work into milestones, that is worth asking about. Milestones are what stop a project becoming one large invoice attached to a promise.
The number you should actually be working out
Before the cost of the build, work out the cost of not building it. Take the process that hurts most, count the hours a week your team spends on it, multiply by what that time is worth, and annualise it. Most businesses are surprised by the size of that figure, and it is the only one that tells you whether the project is worth doing at all.
That calculation is the first thing we do in the free audit — and if it comes out small, we will tell you so.