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.
Look for understanding before answers
A useful first conversation includes questions about your users, constraints and the decisions already made. Be cautious when a supplier recommends a full architecture before understanding the problem. Ask them to explain which assumptions could change their recommendation. You are looking for a partner who can make uncertainty manageable, rather than one who pretends it does not exist.
Take one awkward part of your current workflow into the conversation. Ask how the team would investigate it and which people they would need to speak with. Listen for a process that produces evidence, not an immediate catalogue of services. A useful partner can explain what they do not yet know and how they would reduce that uncertainty before making a substantial commitment on your behalf.
Ask who will actually do the work
Meet the people responsible for design, engineering and delivery, and clarify which roles are dedicated or shared. Discuss how staffing changes are handled and how knowledge stays with the project. An impressive presentation is not evidence of a dependable delivery team. Ask for a demonstration of the team’s working rhythm and the materials you would see during a normal fortnight.
Ask a delivery lead to walk through a recent planning cycle using material they are permitted to share. What did the team intend to complete, what changed and how was the client involved? Confidential details can be removed without losing the shape of the process. This conversation helps you understand how the proposed working relationship will behave when something is unclear or takes longer than expected.
Review work in context
A polished screenshot tells you little about the original constraints or the operational result. Ask what the team changed, what tradeoffs they made and what they would do differently. Verify client references where available and distinguish concept projects from real delivery evidence. Outcomes are more meaningful when they include a baseline, measurement period and explanation of other contributing factors.
For a reference conversation, ask about communication, handover and what happened when the scope changed. These questions often reveal more about a partnership than a headline conversion metric. A concept portfolio can demonstrate design and technical thinking, provided it is clearly identified. It should never be presented as evidence that a real organisation achieved an outcome the supplier has not verified.
Read the handover before the kickoff
Clarify ownership of source code, design files, infrastructure accounts, domains and documentation. Discuss third-party licences, support boundaries and what happens if the relationship ends. You should know how to access your assets and operate your product without relying on an individual’s personal account. A clear exit path is a sign of a healthy partnership.
Walk through an exit scenario before signing. Your internal team should know which accounts it controls, how repositories are accessed and where the latest operational documentation lives. Clarify any continuing licence obligations and what assistance is available during transition. These arrangements are not a prediction that the relationship will fail; they give the business a practical basis for owning what it is paying to create.
Compare the delivery approach
Look for transparent assumptions, a shared backlog, regular demonstrations and a process for changes. Ask how risks are escalated and how the team handles work that takes longer than expected. Understand what is included in testing and what evidence you will receive before release. A good process makes difficult conversations easier because everyone can see the same facts.
Ask how the supplier handles a requirement that proves more complicated after investigation. You should hear a clear explanation of escalation, options and approval rather than a blanket assurance that every change will be absorbed. Make the acceptance process equally explicit. A shared definition of completion helps both parties distinguish a defect, an unfinished requirement and a new idea worth planning separately.
Choose a relationship you can work in
Location can help with workshops and overlapping hours, but it does not replace communication quality. Agree on decision-makers, response expectations and how feedback will be consolidated. Start with a bounded engagement if the relationship is new. The best partner helps your organisation become more capable and gives you a clear view of what you are investing in.
A bounded first engagement can be a useful way to test fit. Choose an investigation with a clear question, deliverables you can keep and an understandable stopping point. Evaluate how the team communicates while doing the work, not just the final presentation. You should leave with a clearer decision and assets your organisation can use, even if you choose a different partner for the subsequent 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.