How to Brief a Developer When You Don't Know What You Need

You know something in your business is broken. Maybe you are drowning in spreadsheets. Maybe you are copying data between three different tools. Maybe your customers keep asking for something you cannot deliver with your current setup. You have a gut feeling that custom software could fix it, but when you try to put your needs into words, you draw a blank.

This is completely normal. Most small business owners are not software people — they are experts in their own trade. You should not need to speak a developer's language to get the help you need. But a little preparation goes a long way. A clearer brief means fewer misunderstandings, fewer wasted hours, and a result that actually solves your problem.

Here is how to get your thoughts together before you pick up the phone or send that first email.

Start With the Problem, Not the Solution

This is the single most important thing to get right. Business owners often come to a developer and say "I need an app that does X, Y, and Z." That is a solution. But if the developer does not understand the underlying problem, they might build exactly what you asked for — and it still does not fix the issue.

Instead, start by describing what is going wrong. What is frustrating you? Where are the bottlenecks? What tasks eat up your time every week? What mistakes keep happening?

For example, instead of saying "I need a customer database," you might say "I have customer information scattered across email, a notebook on the counter, and a shared Google Sheet. When a regular customer comes in, I cannot quickly see their order history or what we discussed last time. My staff have no way to look this up either, so they ask me or just wing it."

That gives a developer far more to work with than a feature request. It tells them what the real problem is, who is affected, and what the current workaround looks like. From there, they can suggest the right solution — which might be simpler or different from what you originally had in mind.

Describe Your Current Workflow

Before a developer can improve your process, they need to understand how it works today. Walk through the steps as if you were training a new employee. Do not skip the messy parts or the workarounds — those are often the most valuable pieces of information.

Try writing it out as a numbered list:

1. Customer calls to place a custom order
2. I write the details on a sticky note and pin it to the board
3. Later that day, I type it into the spreadsheet
4. I email the supplier with the specifications
5. When the supplier confirms, I update the spreadsheet and text the customer
6. When the item arrives, I check the spreadsheet to find the customer's phone number and call them

A workflow like this reveals several things a developer needs to know: there are multiple data entry points, information is being duplicated manually, and communication happens across different channels. A good developer will spot opportunities to streamline this that you might not have considered.

Know Who Will Use It

Think about everyone who will interact with the software. Is it just you? You and two employees? Your customers as well? Each user type has different needs, different levels of technical ability, and different reasons for using the system.

A workshop manager needs to see the big picture — all orders, all statuses, all deadlines. A bench worker needs to see only their assigned tasks and mark them as done. A customer needs to see their order status and nothing else. These are very different interfaces, and knowing this upfront saves a developer from building the wrong thing.

Also be honest about technical ability. If your staff are not comfortable with computers, say so. That is not a problem — it just means the interface needs to be simpler. A developer would rather know this at the start than discover it after building something your team refuses to use.

Gather Examples of What You Like (and What You Hate)

You probably already use software in your personal or business life that does some things well and other things badly. These references are incredibly useful for a developer.

"I like how Shopify lets me see all my orders on one screen with colour-coded statuses." That tells a developer you value a dashboard-style overview with visual indicators. "I hate how our accounting software makes me click through five screens just to create an invoice." That tells them you want fewer clicks and a streamlined process.

Screenshots are even better. If you see something in another app that is close to what you want, take a screenshot and circle the bits you like. This is not about copying another product — it is about giving the developer a visual reference point so you are both picturing the same thing.

Be Clear About Your Constraints

Every project has constraints, and the sooner they are on the table, the better. The main ones to think about are:

• Budget. You do not need to give an exact figure, but a ballpark helps. There is a big difference between "a few hundred" and "a few thousand," and it changes what is realistic to build. If you are not sure what something should cost, our pricing page gives you a starting point — and a good developer will give you honest guidance.
• Timeline. Do you need this by a specific date? Is there a seasonal deadline, a product launch, or a contract renewal driving the urgency? Or is this a "when it is ready" situation?
• Existing tools. What software do you already use that the new system needs to work with? Shopify, Xero, Google Workspace, a specific email provider? Integration requirements can significantly affect scope and cost.
• Data. Do you have existing data that needs to be migrated into the new system? How much? What format is it in — spreadsheets, paper records, another database?

What a Good Brief Looks Like

You do not need a formal document or a detailed specification. A good brief can be an email that covers these five areas:

1. The problem: What is going wrong or what is missing in your current setup
2. The current process: How you handle things today, step by step
3. The users: Who will use the software and what they need from it
4. Examples: Things you have seen that you like or dislike, with screenshots if possible
5. Constraints: Budget range, timeline, existing tools, and any non-negotiable requirements

That is it. You do not need to specify technologies, write user stories, or create wireframes. Those are the developer's job. Your job is to explain the problem clearly and provide enough context for them to propose a solution.

What Not to Worry About

Do not worry about using the "right" terminology. If you call a database a "list of customers" and a dashboard a "screen that shows everything at once," that is perfectly fine. A good developer will translate your language into technical requirements. What matters is that the meaning is clear.

Do not worry about asking for too much. It is better to share your full wish list and let the developer help you prioritise than to hold back and end up with something that misses the mark. Most projects are built in phases anyway — you start with the essentials and add features over time.

And do not worry if your ideas change during the conversation. That is how the process is supposed to work. A good developer will ask questions that help you refine your thinking. The brief is a starting point, not a contract.

Red Flags to Watch For

While we are on the subject, here are a few things that should make you cautious when talking to a developer:

• They do not ask questions. If a developer hears your brief and immediately starts quoting a price, they have not understood the problem. Good developers ask a lot of questions before proposing anything.
• They push a specific technology. You should not need to care whether the backend is built in Python, Ruby, or JavaScript. If a developer is selling you a technology stack rather than a solution, they are focused on the wrong thing.
• They cannot explain things simply. If you do not understand their proposal, that is their problem, not yours. A developer who cannot communicate clearly with non-technical people will struggle to build something that actually fits your needs.

Ready to Start?

If you have been putting off reaching out to a developer because you did not know where to begin, hopefully this gives you a roadmap. You do not need all the answers — you just need to describe the problem honestly and share enough context for a developer to start asking the right questions.

At JMS Dev Lab, we specialise in building custom software for small businesses — from Shopify apps to standalone tools for managing repairs, tracking commissions, and streamlining workflows. We have worked with business owners who started with nothing more than a frustrated email, and we are comfortable working from there.

If you have a process that is not working, a spreadsheet that has outgrown itself, or a vague idea that you cannot quite articulate, get in touch. We will help you figure out the rest.

You might also find these posts useful: Have You Outgrown Spreadsheets? covers the signs that your business has hit the limits of what a spreadsheet can handle, and our service packages page shows the kinds of projects we typically take on.

Related Reading

• Hiring a Developer for the First Time
• Our Pricing