Engineering and commercial decisions

How to Evaluate the Cost of Custom Software

Assess software estimates through deliverables, approved effort, dependencies and ongoing ownership rather than comparing headline totals alone.

Make the scope comparable

Before comparing totals, ask what each proposal lets your users actually do. “Customer portal” could mean a place to download documents, or an application where different users submit work, review it and approve the next step. Those descriptions need different estimates, even when both proposals use the same label.

Use a representative task to compare the scope. For example: a customer signs in, finds their document and downloads it. Ask each supplier to explain which parts of that task are included, who provides the documents, and how you will check that a customer can access only the right material. If another proposal includes document uploads and staff approval, put those differences beside the price. You can then decide whether you need the extra workflow.

Check migration, content preparation, training and launch work separately. A lower total may leave your team with more work to do; make that workload visible before choosing.

Separate known labour from uncertain scope

Ask for the activities and hours behind the estimate, including which allowances are agreed and which still depend on investigation. Webvelopment’s planning tools use R850 per hour excluding VAT; activities without an allowance remain custom scope and need their own estimate.

For example, an approved five-hour task would be 5 × R850 = R4,250 excluding VAT. That shows the cost of the approved effort. It does not establish that a particular integration can be delivered in five hours. If an estimate includes an integration allowance, ask what information it assumes is available and what happens if that assumption proves wrong. Keep infrastructure, licences and provider transaction fees separate so you can see what the labour total covers.

Include life after launch

Ask who will handle support, monitoring, backups and platform updates, and how you will request future changes. Include your team’s responsibilities: who reports a problem, who can approve a change, and who keeps content current? Separate the once-off implementation price from recurring service costs so a launch budget does not hide the cost of running the software.

If an unresolved question could change the scope substantially, consider discovery before approving implementation. Ask for a specific output that helps you decide, such as a documented workflow and a list of integration assumptions still to check. An indicative calculator result is a planning aid; the final scope and price still need agreement. Any credit from discovery towards implementation also needs to be agreed explicitly.

Apply this to your brief

Bring the current workflow, a representative example and the decision you need to make. A useful starting point is to show what someone does today, where they get stuck, and what the proposed software should let them do instead. If you already have competing estimates, mark the tasks that appear in only one of them and the costs that recur after launch. Those gaps give us something concrete to discuss.

Explore Willan’s consulting approach, review development services or discuss your project.

Planning guidance from Webvelopment Editorial. Confirm platform requirements and project assumptions before committing budget.

Let’s move things forward

Start a conversation

Tell us what you are working towards. We’ll help you find a practical next step.

Discuss your project