Prepare a useful project brief
You do not need a technical specification before the first conversation. A useful brief gives the developer enough context to understand the problem, ask better questions, and identify what still needs a decision.
Explain the work as it happens today
Start with what your business does and who will use the software. Walk through the current process in plain language: where a request begins, which tools it passes through, and who decides that it is finished.
Describe the point that causes trouble. “We copy each approved order into another spreadsheet” is easier to investigate than “we need something modern.” If you do not have an existing process, describe the first task a new user should be able to complete.
Separate the outcome from a feature list
Features are possible ways to achieve an outcome. A dashboard might help, but the real requirement could be knowing which requests need attention. Share the result you want and let the implementation be discussed.
List the essential actions separately from later ideas. For each essential action, add an example of what counts as correct. A file importer, for instance, may need to identify duplicates, explain rejected rows, and preserve identifiers with leading zeros.
Make constraints visible early
Share your target deadline, why that date matters, and any fixed dependencies such as an existing website, approved platform, or third-party account. A budget range is useful if you are comfortable sharing it; if it is undecided, say so.
Identify who can review the work and who can approve changes. Include responsibilities that continue after launch: content updates, hosting, domain access, and project-related support. A quotation should state its assumptions and agreed scope.
- Business and intended users
- Current process and main difficulty
- Essential result and later ideas
- Existing tools and integrations
- Target date and budget context, if known
- Review, handoff, and ongoing responsibilities
Use fictional examples for the first discussion
A representative screenshot or small sample file can explain more than a long feature list. Remove customer records, employee details, credentials, and anything you are not allowed to share. Label fictional examples so nobody mistakes them for measured business results.
For a quotation from Tristan, the next step is a conversation about your business, requirements, and target deadline. He prepares pricing personally. His stated payment arrangement is a 50% down payment and 50% on completion; the proposal confirms the scope and terms for the specific project.
What to take away
A short, concrete brief with open questions is enough to begin. It should make the problem understandable without pretending every implementation decision is already settled.