What you should, and shouldn't, pay for in custom software

You have three quotes in your inbox for the "same" project, and the numbers don't agree. That isn't unusual, and it usually isn't anyone being dishonest. Each developer quoted a different project, because nobody wrote down what the project is. I've been building software for South African businesses since 2011. Here's what you shouldn't pay for, what actually drives cost, and how to get a quote you can trust.

What You Should Not Pay For in 2026

You shouldn't pay senior rates for ceremony that doesn't move the project forward. You shouldn't pay for a discovery process that produces attractive diagrams but no buildable scope. A useful plan leaves you with decisions: what gets built first, what waits, what data is needed, which integrations are risky, and what the first working version should do. You shouldn't pay for a rewrite because the new developer doesn't like the old developer's code. Sometimes a rebuild is right. Often the cheaper answer is a controlled rescue: audit the code, stabilise the risky parts, then improve it in phases. You shouldn't pay for a large team when the project needs one senior person who understands the workflow and will tell you honestly where custom software is the wrong choice. And you shouldn't pay for vague "AI-powered" features unless somebody can explain what the AI does, what data it uses, how failure is handled and what a person can override.

Why Quotes Vary So Much

When you ask three developers to quote on "a booking system" or "a customer portal," each one imagines a different thing.

Developer A hears "booking system" and quotes a form connected to a calendar.

Developer B hears "booking system" and quotes a multi-location booking platform with staff management, payment integration, automated reminders, and a customer-facing portal.

Developer C is an agency. They hear "booking system" and quote discovery workshops, UX research, wireframes, design sprints, development, QA, deployment, and a support contract.

None of them are wrong. They are quoting different things because the scope was not defined.

The most important thing you can do before asking for quotes is define what you actually need. Not how it should look. What it should do. What data goes in. What comes out. Who uses it. What happens when something goes wrong.

What Drives Cost

Four factors determine what custom software costs.

1. Complexity

A simple CRUD application (create, read, update, delete records) is straightforward. Think: a task tracker, a simple CRM, a product catalogue with admin.

A complex application has business logic, conditional workflows, multi-user permissions, real-time data, reporting, and integrations with external systems. Think: a POS system processing thousands of transactions daily, a medical practice management system with billing and clinical records, or a multi-branch operations platform.

Simple applications cost less because they have fewer moving parts. Complex applications cost more because every edge case, every rule, and every integration point takes time to build correctly.

2. Integrations

Does your software need to talk to other systems? Payment gateways (PayFast, Yoco, Peach). Accounting software (Xero, Sage). Email systems. SMS providers. ERPs. Logistics APIs.

Each integration is a separate piece of work. The difficulty varies wildly. Integrating with a well-documented API takes a day. Integrating with a legacy ERP that uses flat-file exports takes a week or more.

3. Number of Users and Scale

Software for a team of 5 people is different from software for hundreds of employees across several branches. Scale affects architecture, hosting costs, security requirements, and performance work.

A system processing a handful of transactions per day can run on simple infrastructure. A system processing thousands of transactions daily needs careful database design, caching, monitoring, and redundancy.

4. Platform

A web application is one platform. Add a mobile app and you have two platforms. Each platform roughly doubles the front-end development effort. The backend can often be shared, but the mobile app itself (or the responsive web version) requires its own design and development.

Solo Developer, Agency or Offshore

A solo developer gives you direct access to the person writing the code, no project manager layer, and fast decisions. The tradeoff is one person's capacity: if the project is genuinely large, a solo developer may not have the bandwidth alone.

An agency gives you a team: designers, project managers, developers, QA, and more capacity for large projects. Good agencies are worth it for that, and I work with agencies often, on the complex builds, integrations and custom work their clients need.

An offshore developer can be excellent. Judge the person and their proof, not the country, the same way you'd judge anyone else.

The right choice depends on your project, your budget, and how involved you want to be.

How to Evaluate a Quote

When you receive a quote, look for these things.

Does it include a scope document? A quote without a scope document is a guess. The scope should describe what will be built, what will not be built, what technologies will be used, and what assumptions were made.

Does it specify what happens after delivery? Who fixes bugs? How long is the warranty period? What does ongoing support cost? A developer who does not mention post-launch support is planning to disappear after the last payment.

Does it include a timeline? "It will take a few months" is not a timeline. Week-by-week or milestone-based timelines show the developer has actually thought through the work.

Does it distinguish between must-haves and nice-to-haves? A good developer will help you prioritize features and suggest a phased approach: build the core first, then add features based on real usage. A developer who says "yes" to every feature in one big quote is either overcharging or underestimating.

Can the developer show you similar work? Not a portfolio of pretty screenshots. Working software they have built that does something similar to what you need. Ask about the scale, the challenges, and whether the client is still using it.

How I Quote

I quote privately once I understand the job. It starts with the written plan: a fixed fee, agreed in writing, and the plan is yours to keep. Then a fixed price for the first working piece, then phases. You pay per piece of work, on the terms written in its quote. There's no single bill for the whole project up front, and you're never committed to more than one piece. See how I work.

A Real Example

I built a custom point-of-sale system for a recycling company, on my own, in 13 months. Seven branches. 350 employees. 5,000 transactions a day. The system handles pricing by weight, multi-branch inventory, cash management, supplier payments, and reporting across the entire operation.

This was not a simple project. It replaced manual and spreadsheet-based processes. It handles real money, real inventory, and real operations every day.