You don’t need a technical specification to start a software project. A clear picture of the work that is frustrating your team is a much better first step.
Use this checklist to prepare for a conversation with a developer. You can leave questions unanswered; part of discovery is working through them together.
1. Describe one real problem
Start with a recent example rather than a list of features. What happened, who was involved, and what took extra time or caused confusion? For example: “We don’t know which branch has an item until someone calls around.”
Separate the underlying problem from your first proposed solution. You may ask for an app, while the real need is a shared stock record that staff can update easily.
2. Map the current process
Write down the steps from beginning to end: what starts the process, who does each step, what information they use, and what happens when something goes wrong. Mention the tools already involved, such as paper forms, spreadsheets, WhatsApp or an existing system.
If you can, bring a blank or anonymised example of a form or report. Don’t send passwords, customer lists, payment details or other sensitive information.
3. Identify the people and places involved
List the types of people who would use the system—such as an owner, manager, cashier or field worker—and what each needs to do. A rough number of users, branches or devices helps shape the conversation. Avoid sharing individual staff or customer details at this stage.
Also note where the work happens and whether connectivity is reliable. If the process needs to continue offline, say so early; it can affect how a system should be designed.
4. Choose a useful first release
Separate essential needs from ideas that can wait. Ask: “What is the smallest version that would make this workflow meaningfully better?” A focused first release is easier to review and gives everyone a clearer way to agree what is in scope.
- Must have: needed for the first version to solve the main problem.
- Later: valuable improvements that can wait until the core process works.
- Unsure: questions to explore during planning, not promises to build.
5. Share constraints and priorities
Think about a comfortable budget range, any important dates, devices your team already has, and systems the new software may need to work with. You don’t need perfect estimates. Saying “we’re not sure yet” is useful information too.
Discuss which trade-offs matter most: keeping the first version affordable, launching by a particular date, supporting a specific workflow, or leaving room to expand later.
6. Agree how you’ll judge the result
Describe what should be easier once the first version is in use. Make it observable: staff can find an order without searching chat history, a manager can review stock from one place, or a customer can submit a request without a phone call. These are goals to validate together, not guaranteed results.
Bring a brief, not a perfect specification
A few notes about the problem, current steps, users, must-haves and constraints are enough to begin. At Vizion, the first conversation is used to understand the workflow and discuss a prototype before you decide whether to proceed.
Share a short project brief or message us on WhatsApp. Please don’t include confidential or sensitive data in your first message.