What a software discovery phase should include in Australia

What a discovery phase actually is

If you are about to spend real money on a software build, the most expensive decision you can make is to skip straight to development. A discovery phase is the short, structured stretch of work that turns "we think we need an app" into a scoped plan you can actually price, schedule, and hold a vendor to.

Discovery is the work of defining the problem precisely enough that the build becomes predictable. It is not design polish, and it is not the first sprint of development. It sits between the idea and the contract, answering four questions before anyone writes production code: what problem are we solving and for whom, what must the first version do and explicitly not do, how will it be built and what must it connect to, and what could go wrong technically, commercially, and operationally.

The output is a decision, not a deliverable for its own sake. By the end you should be able to say "proceed with this scope at roughly this cost", "change the scope", or "stop, this is not worth building". Any of those three is a good result. A discovery that can only ever conclude "yes, keep paying us" was a sales call.

Why skipping discovery costs more later

The appeal of skipping discovery is obvious: it feels like paying to talk instead of paying to build. The problem is that the unknowns do not disappear when you ignore them. They surface mid-build, when changing direction is most expensive.

Without a defined scope, three things tend to happen. Estimates are guesses, so the project either gets padded heavily to cover risk or quoted low and topped up later through change requests. Requirements drift, because nobody agreed where version one ends, so every conversation adds "just one more thing". And integrations turn into surprises, because the dependency on an accounting system, a payment provider, or a legacy database was discovered halfway through rather than mapped up front.

A modest discovery investment is essentially buying down that risk. A cost estimate built from a documented scope is a number your business can commit to. A number pulled from a thirty-minute chat is a hope.

What a good discovery includes

A useful discovery is a small set of concrete activities and a small set of concrete outputs. The activities are how the vendor learns your business; the outputs are what you keep.

The activities usually include stakeholder interviews and a working session to surface goals and the real current process, workflow mapping of how the job is done today including the messy manual workarounds, a technical review of the systems the solution must integrate with, scope definition that separates version one from the backlog, and risk identification across delivery, security, data privacy, and maintenance.

• A scoped feature list for version one, with an explicit "not in this version" list.
• The primary user flows, often as wireframes for the most important screens.
• An architecture and integration plan describing the stack and the connections.
• A risk register naming the things most likely to cause delay or cost, with a plan for each.
• A development estimate, ideally as a range with the assumptions written down.

What discovery costs in Australia

Costs vary with the size and risk of the build, so treat every public range as planning guidance, not a quote. Published vendor guidance commonly prices discovery as a small percentage of the expected development budget, often around 5 to 15 per cent depending on depth, integrations, and how much product design is included.

For Australian small-to-medium builds, that often translates to a practical planning band somewhere around A$5,000 to A$20,000. A tightly scoped MVP discovery can sit at the lower end; a discovery that has to untangle several legacy systems and stakeholder groups sits higher. The useful question is not "how cheap can discovery be?" but "what uncertainty does this work remove before we commit to the build?"

Treat any discovery that is free or suspiciously cheap with caution. Genuine discovery costs the vendor senior time, so when it is given away it is usually a lightly disguised sales process designed to produce a "yes", not an honest assessment that might produce a "no". The point of paying for discovery is precisely that the vendor is free to tell you not to build.

Telling a real discovery from a sales pitch

The format of a discovery is easy to imitate. The substance is harder to fake. A real discovery is willing to recommend against the project, or against its current scope. It produces artefacts you can take elsewhere — the scope, risk register, and estimate should be useful even if you pause or change vendors. It spends real time on your actual systems and data rather than talking in generalities, and it names risks plainly, including the unflattering ones about timeline, integration, and maintenance.

A weak discovery does the opposite. It is heavy on enthusiasm and light on constraints, avoids committing to a scope boundary, and leaves you with a glossy proposal rather than a plan you could hand to a different engineer and have them understand. If you cannot tell what is in version one and what is not, the discovery has not done its job.

How we run discovery at QuantamQ

At QuantamQ a discovery is deliberately short and decision-focused. We map the workflow, review the systems it has to touch, define a version-one scope with an explicit cut line, write down the risks, and return an estimate as a range with the assumptions attached. For builds replacing manual processes or spreadsheets, that work flows straight into delivery; for AI features, it pairs with a feasibility check run against your real data rather than a demo on clean sample data, because the gap between the two is where most AI projects quietly fail.

The aim is the same every time: make your next decision cheap and well-informed. Whether that decision is to build, to narrow the scope, or to walk away, you should finish discovery owning a clear picture of the work — not a sense of momentum manufactured to get you to sign.