The most expensive software problems are decided before development starts. A project that begins with a clear written scope tends to finish close to its estimate. A project that begins with a general idea tends not to.
Describe the process, not the software
The most useful thing you can bring to a first conversation is a description of how the work happens today. Who receives the request, what they do with it, what they check, who approves it, and where it gets stuck.
Developers can design software. Only you can explain the operation. A vague brief forces the developer to guess, and guesses are what turn into change orders.
Name the one thing that has to work
Every project has a primary outcome. Cutting the time to produce a quote. Eliminating duplicate entry between two systems. Giving field crews something that works without signal.
Naming that outcome makes every later scope decision easier, because features can be judged against it rather than against personal preference.
Separate must-have from nice-to-have early
Almost every requirement list contains items that would be pleasant but change nothing operationally. Sorting these before development starts is what keeps a first release small enough to actually ship.
- What breaks the business if it is missing at launch
- What can wait until the second release without causing harm
- What is really a preference rather than a requirement
- What is already handled adequately by an existing tool
Ask for the boundaries in writing
A proper proposal should state what is included, what is excluded, what the client is responsible for providing, and what happens when scope changes. Vague proposals are not friendlier. They just move the disagreement to a later and more expensive point in the project.
You should also expect to be told when something is not worth building. A developer who agrees to everything is not necessarily giving you good advice.
