How to Brief a Software Developer When You're Not Technical

One of the biggest things holding business owners back from building custom software is not budget or trust. It is the quiet fear that they will not be able to explain what they need. If you are not technical, “briefing a developer” can sound like it requires a vocabulary you do not have.

Why you don't need technical language to start

Good developers do not expect a technical specification from you. Producing that specification is their job, not yours. What they need is a clear and honest description of how work happens today, including the messy parts.

Think of briefing an architect for a house renovation. You do not need to calculate load-bearing walls. You need to explain how you use the kitchen, what frustrates you about the layout, and what you want to do that is currently impossible. The architect translates that into technical decisions. A good software developer does the same with your business process.

What a good discovery process should extract from you

If a developer or agency discusses technology, platforms, or architecture before understanding your process, treat that as a warning sign rather than proof of expertise. Good discovery begins with questions you can answer without any technical knowledge.

Questions about the process itself

• Walk me through what actually happens from start to finish, including the workarounds—not the idealised version.
• Who is involved at each step, and what do they need to do?
• Where does information live today: spreadsheets, email, paper forms, or someone's memory?
• Where does the process break down or slow down? Your current frustrations are valuable input.
• What happens in the exceptions? The unusual client or order often reveals more than the happy path.

Questions about the people

• Who uses this process regularly, and how comfortable are they with technology? This determines how simple the tool must be.
• Who might be frustrated by the change, and why? Understanding resistance early helps avoid building something people quietly refuse to use.

Questions about the goal

• What does “better” mean: faster work, fewer errors, less dependence on one person, or more visibility? Specific outcomes matter more than technical detail.
• What would your team do with the time this change gives back? The answer separates essential outcomes from features that are merely nice to have.

None of these questions requires knowledge of databases, platforms, or code. They require knowledge of your business—which you will always understand better than an outside developer.

What to bring to the conversation

• Examples of the documents, spreadsheets, and forms used today, even when they are messy. These are valuable evidence of the real process.
• A rough sense of priorities: if only one problem could be fixed first, which would matter most?
• Honesty about what is not working, even if the current process feels held together with tape.

What not to worry about

• Knowing which technology should be used. The developer should recommend it, not ask you to specify it.
• Having a complete, polished process description. Discovering the undocumented parts is part of good discovery.
• Sounding technical. Plain and specific descriptions are more useful than jargon you do not fully own.

Red flags in vendors who make you feel dumb for not knowing the jargon

Not every developer or agency runs a good discovery process. Look for these warning signs before making a commitment:

• They lead with technology rather than your process. Frameworks and architecture should not come before understanding how the business works.
• They make you feel that you should already understand technical terminology. A good partner translates; they do not quiz.
• They demand a technical specification before discovery. Producing that specification from conversations with you is their job.
• They quote or propose before understanding exceptions and edge cases. Those cases often contain most of the real complexity and cost.
• They cannot explain their understanding back to you in plain language. If they cannot summarise your process in your own terms, they probably do not understand it yet.

The bottom line

Briefing a developer is a business exercise, not a technical one. You are not expected to know how to build the solution. You are expected to know your business, including its messy, undocumented, workaround-filled reality. If a development partner cannot extract that knowledge without requiring you to speak their language first, that reflects on them—not on you.

The businesses that get the best results from custom software are not those with the most technical founders. They are those that can describe their own process honestly, including the parts that do not work.