Good technology decisions start with a clear problem and a realistic view of the work involved. This guide sets out the questions we would bring into a discovery conversation, the tradeoffs to examine and the evidence worth collecting before committing to a delivery plan. The aim is practical clarity for Australian product teams and business owners.
Start with the product, not a price tag
An app is not a single unit of work. A booking tool for an existing service and a marketplace with payments, identity checks and dispute handling have very different cost structures. Before discussing a number, write down who the app serves, the action it helps them complete and the systems it must connect to. A concise problem statement makes an estimate more useful than a long wish list.
A booking app is a useful example. “Let people book an appointment” leaves several decisions open: can they choose a practitioner, pay a deposit, cancel, join a waiting list or book on someone else’s behalf? Each choice changes the workflow and the amount of testing. Sketch the simplest complete booking journey first. Then put the additional options beside it, rather than treating every possibility as part of the first release.
The five decisions that shape your budget
Platform choice, feature depth, integrations, operational risk and the quality of your existing assets account for much of the variation between proposals. A cross-platform interface can share substantial code, but native features still need platform-specific testing. An integration with clear documentation is different from a legacy system accessible only through a fragile export. Ask the delivery team to expose those assumptions rather than hiding them in a single figure.
Ask for an estimate that separates the product experience from the work around it. A screen may be straightforward while the permission model behind it is complex. Integrating payments also means deciding how refunds, failed transactions and reconciliation work. Your proposal should describe those behaviours. Without that detail, two suppliers can use the same feature name while pricing very different responsibilities.
Budget beyond the first release
Your first build is only part of ownership. Hosting, third-party subscriptions, app store administration, customer support, dependency updates and product improvements need ongoing funding. Set aside time for accessibility checks and testing on real devices. Separate unavoidable operating costs from discretionary roadmap investment so you can make informed decisions when revenue or priorities change.
Prepare a small ownership worksheet with three columns: monthly services, planned maintenance and product changes. Put an owner beside each line. For a subscription product, include the cost of answering customer questions and resolving failed billing events. For a staff-facing app, include device support and training. These costs need not all sit with your development partner, but they should sit somewhere in the plan.
Compare proposals on the same basis
Ask each supplier for a common scope, milestone schedule, exclusions and acceptance criteria. Check whether discovery, research, design, testing and handover are included. Clarify whether quoted amounts include GST and which currency applies to third-party tools. An unusually low proposal may simply assume more of your team’s time. That can be appropriate, provided everyone understands their responsibilities.
Watch for qualifications hidden behind familiar words. “Testing included” might mean an engineer checks their own work, or it might include a documented device matrix and independent review. “Deployment included” might stop at the app store submission. Ask who handles rejected submissions, production configuration and the first week of support. Written answers make the comparison fairer and reduce surprises for both sides.
Use discovery to reduce expensive uncertainty
A short discovery phase can test a risky integration, validate a customer journey or resolve an architectural decision before full delivery begins. Its output should include a prioritised release scope, a dependency map, a costed delivery plan and explicit open questions. You should be able to take those materials to another team. Discovery is valuable because it changes a decision, not because it produces a large slide deck.
A useful discovery output is a range with reasons. The lower end might assume a documented integration and an existing design system; the upper end might include a migration or an additional approval stage. Identify which investigation would narrow that range most. Spend discovery effort there. An estimate becomes more credible when the team can show how a new piece of evidence changed it.
A practical brief to take into your first conversation
Bring your primary user journey, three essential features, existing design assets, integration documentation and a realistic launch constraint. Explain why the date matters. Decide who can approve changes and how quickly they can respond. We do not publish a universal app price because it would disguise too many assumptions; our project planner helps prepare the information needed for an honest estimate in AUD.
At the end of an initial conversation, you should understand the next decision—not simply have a more elaborate list of features. Ask what information the team needs to prepare a proposal, who will review it and when the scope becomes a delivery commitment. If you are still comparing options, say so. A responsible partner should be comfortable helping you define a bounded investigation before proposing a full build.
Bring the right questions to the table
Before choosing a supplier or solution, write a short decision brief. Describe the outcome you need, the constraints you cannot change and the assumptions you can test. Ask your team to review it from the perspective of customers, operations and ongoing ownership. Differences in those perspectives are useful: they often reveal an overlooked requirement before it becomes expensive to change.
You do not need a perfect specification to begin a conversation. You do need a shared understanding of the next decision. BonsaiCo can help frame a discovery engagement, work through options and prepare a practical delivery plan. Start small, make the work visible and let evidence guide the next stage of growth.