Start with a request, not a feature list.
Take a recent order, booking or customer enquiry. Write down where it arrived, who picked it up, what they checked and what happened next. Include the spreadsheet, the message thread and the person who knows the answer without looking it up. That is the beginning of a software brief.
A feature list says you need a dashboard. Following a request tells you who needs to see it, which information they need and what decision the dashboard should make easier. The second conversation is much more useful when you are paying someone to build.
Look closely at the handoffs.
The most revealing moments are often between tasks. Someone copies an address into another tool. A manager approves a price in a chat. A customer calls because the status on screen does not explain what is happening. These are places to investigate, not automatic reasons to commission a new platform.
For each handoff, note the source of the information, the person responsible and the condition that allows the work to move on. Then follow an exception. What happens when the payment fails, a date changes or the person responsible is away? A useful system gives those situations an explicit place.
Compare changing the process with changing the software.
A new tool is not always the right answer. A clearer responsibility, a better form or a connection between two existing products may remove the problem. Custom software becomes a stronger option when the workflow is distinctive, the existing tools impose meaningful constraints and the business can support the system after launch.
Ask a prospective studio to compare those options. The discovery work should leave you with a recommendation and its reasons, including the option to build less. GOV.UK’s discovery guidance makes a useful distinction: understand the problem before committing to building a service. That principle is useful well beyond government projects.
Define a release that can finish.
Choose one complete journey for the first release. For example, a customer submits a request, an operator reviews it, the customer receives a decision and both can see the record. A smaller journey that works through to the end is easier to assess than five partially implemented modules.
Write the acceptance conditions in plain language. Who can change the record? What does the customer see when a request cannot be fulfilled? What information must survive a failed integration? Agree the conditions before estimating the build, and keep a separate list of later ideas.
Budget for ownership as well as delivery.
The build price is only one part of the decision. Someone will need to own hosting, access, updates, backups, support and the relationship with external services. Ask what is included in the handover and who will have the accounts and source code.
A useful first meeting does not require a polished specification. Bring a real example of the work, the tools it passes through and the point where it becomes difficult. That gives a studio something concrete to challenge, simplify and price.
