How to commission custom software and keep the budget under control

August 2026 · 3 min read · Datawise Consulting, Hobart

Having software built is closer to building a house than to buying one that is already standing. It can suit exactly the way you work, but you carry every decision, and every surprise found part way through.

1. Establish first whether an off-the-shelf product will do

Before scoping anything, check properly whether an existing product already does the job. If one does, buy it: somebody else funds its maintenance, and it can be in use far sooner.

Custom software earns its keep where the way you work is particular to your organisation, or where no product covers your process without somebody re-typing information from one system into another.

2. Agree the requirements before the price

A figure given before anyone has understood the requirement is a guess, and guesses tend to be corrected later through variations. Settle the requirements first: how your organisation works, what the system has to achieve, and the budget and timeframe it has to fit.

On a larger project, treat this as a stage of its own. It ends in a written specification and a quote, and you can stop there if the numbers do not make sense.

3. Build in stages

Build the part that removes the largest manual step, put it into use, and let real use determine the next stage. Features that looked essential on the original list often stop mattering once people are working differently.

Along the way, regular check points let you see how the system compares with what you expected, and say so while it is still easy to change.

4. Involve the people who do the work

The expensive discoveries happen late, and they are often the same one: the documented process is not what actually happens. There is a workaround, an exception, or a spreadsheet somebody maintains on their own computer.

Found during scoping, that is a short conversation. Found during testing, it is a rebuild.

5. Be careful what you ask to be automated

Automating a process exactly as it runs today can be a mistake: some manual steps exist only to work around a limitation that disappeared years ago. Ask whether you would still design the process this way from scratch.

6. Budget for the years after delivery

Software is not bought once and left alone. Operating systems change, security updates keep arriving, and so does the organisation it was built for.

A modest annual allowance for maintenance and small changes is normal, and far cheaper than letting a system drift until replacing it is the only option.

A system that has already drifted does not always need replacing from scratch. Older Microsoft Access and SQL Server systems can often be migrated into maintainable web applications, keeping the data and the parts of the process that still work.