Why preparation matters
The clearer your starting point, the more accurate the quote and the fewer surprises later. You do not need technical knowledge to prepare well. You need to be clear about the problem and the people it affects.
1. The problem in one paragraph
Describe what is not working today and what it costs you: time, money, lost customers or mistakes. A good brief starts with the problem, not the solution.
2. Who will use it
List the kinds of people who will use the software, such as customers, staff, managers or partners, and the main thing each of them needs to do.
3. The must-haves and the nice-to-haves
Split your wish list in two. The must-haves define the first version. The nice-to-haves can follow once the core is working and paying for itself.
4. What it must connect to
Note the systems already in use: accounting software, payment providers, email, spreadsheets, an existing website. Connections are often where the real work is.
5. Budget and timing
Share a budget range and any fixed dates, such as a launch, an event or the end of a contract. It lets the developer suggest the right scope instead of guessing.
6. Questions to ask every developer
Who owns the code when it is finished? How often will I see working software? What happens after launch, and what does support cost? Can I speak to a past client? Clear answers to these tell you more than any portfolio.