Most discovery calls go well when both sides arrive with something written down. Ours are 20 minutes with a senior person. That is enough time to see whether there is a fit. It is not enough time to reconstruct your business from a one-line email.
A brief can be short. It still has to be honest about the operation, the people, and the outcome you want. We would rather decline a project than win one we should not have. A clear brief makes that call possible on both sides.
What to write before you book the call
Start with the work as it exists today. Who does it, how often, and what breaks when it goes wrong. Spreadsheets, email chains, and shadow systems are useful to name. They tell us more than a future-state diagram.
Then name the outcome. What should be true in six months if this goes well. Hours back for a specific team, fewer hand-offs, a customer seeing one record instead of several. Pick an outcome you can recognise in the operation.
Write down who will live with the thing. The operations lead, the field staff, the person who will own the budget after launch. We want to meet the people doing the work. The people who only approve it can join, but they should not be the only ones in the room.
If you already have systems in the mix, list them. CRM, finance, identity, a warehouse tool, a spreadsheet that has become a database. Integrations move cost and risk more than most briefs admit. You do not need an architecture diagram. Names and what each system is used for is enough.
Constraints that save everyone time
Ownership should be explicit. Code, infrastructure, and accounts should sit with you from day one. If a previous vendor still holds GitHub, AWS, or the app store listings, say so. That is a handover we can plan for, and a poor surprise in week six.
Data residency and privacy belong in the brief if you handle personal information. The Australian Privacy Act applies to systems that process personal data. Skip the legal memo. Say what data is in play and whether it can leave Australia.
Say how you like to buy the work. A fixed-price sprint, an open-ended retainer, and a phased build are different commitments. The brief should match your appetite for change, because the scope will change.
If you have a date that is real (a season, a board meeting, a contract), put it in. If the date is a wish, say that too.
What you can leave out
Leave the stack open. We work on platforms with deep talent pools so you can add an engineer later or bring the work in-house. A brief that locks a framework before anyone has seen the operation usually has to be unwound.
A twelve-month feature list can wait. A small first increment that can sit in users' hands every fortnight is more useful than a roadmap that assumes the first version was right.
Skip the fixed price for a six-month build. Anyone quoting that from a paragraph is guessing. For most engagements we run a paid discovery sprint of one to two weeks, fixed price, and write an estimate with the assumptions and risks on the page.
How we use the 20 minutes
We will ask who will do the work on your side, and we will tell you who would do it on ours. Names and how much of their week the project gets.
We will ask what you typically do not want us to do. If you need a partner who will build the first thing, say that. If you already have an internal team and need a burst of senior help, say that too.
Bring the questions you would ask any vendor: how change is handled, who you call when something breaks at 11pm, and what offboarding looks like. A first conversation should leave both sides with a sense of fit and a short list of next steps.
If you have a page of notes, send it through the contact form before the call. The shorter the better. We will come back with questions.
