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.
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.
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:
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.
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.
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.
Every project has constraints, and the sooner they are on the table, the better. The main ones to think about are:
You do not need a formal document or a detailed specification. A good brief can be an email that covers these five areas:
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.
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.
While we are on the subject, here are a few things that should make you cautious when talking to a developer:
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.