A common reason people put off talking to a software developer is the feeling that they need a proper plan first. They do not. A good developer will help you shape the problem. But a few simple answers will make that first conversation much more productive.
1. What is the problem, in one sentence?
Not the solution, the problem. "We lose track of which jobs have been quoted" is better than "we need an app". If you cannot say it in a sentence, write two or three and see which feels truest.
2. Who is affected?
List the people who deal with the problem: staff, customers, managers, suppliers. Software succeeds or fails on how well it fits the people using it, so it helps to know who they are.
3. How does it work today?
Describe the current process, mess and all. Which tools are involved? Where do things get stuck? What do people do to get around it?
4. What would "better" look like?
You do not need to be precise. "Quotes go out the same day" or "I can see the whole picture without asking three people" is plenty.
5. What systems already exist?
Accounting software, a CRM, a website, spreadsheets. Software rarely lives alone, and knowing what it needs to connect to shapes the plan.
6. Is there a deadline or a constraint?
A busy season, a compliance date, a fixed budget. Constraints are not obstacles to hide, they are useful information.
7. Who will make decisions?
Projects move faster when there is one clear person on your side who can answer questions and say yes or no.
A one-page checklist
Before the call, jot down: the problem in a sentence; who is affected; how it works today; what a better outcome looks like; any hard deadline; the systems it must connect to; and who decides. If you have a sample of the spreadsheet, form or report involved, bring that too. Real examples beat descriptions every time. Our post on writing a software brief has a template.
What a good developer will bring
Expect questions, not a sales pitch. A good first conversation covers who uses the system, what goes wrong today, what happens if nothing changes, and what the smallest useful first step would be. If you leave the call with a clearer view of your own problem, it was a good call, whether or not you work together.
What you do not need
You do not need wireframes, a technical specification, or to know which technology to use. You do not need to know what it will cost. Understanding that is part of the conversation.
If you can answer even three or four of these questions, you are ready. Write them down, send them over and see what comes back.