There is a moment that most business owners recognise, usually a few weeks into a development project. You asked for something that seemed perfectly clear. The developer built exactly what you described. And yet the result is not what you meant at all. Nobody lied and nobody was careless. The problem started before a single line of code was written, in the gap between the idea in your head and the words you used to describe it.
That gap is wider than it looks. When you picture your new app, you are drawing on years of experience in your own industry — pricing rules, customer habits, edge cases, the way orders flow, what 'approved' actually means in your business. Your developer has none of that context. They are skilled at turning precise instructions into working software. They are not skilled at reading minds, and it is unreasonable to expect them to be.
The good news is that the fix is not complicated. It involves writing things down, drawing rough pictures, and agreeing on what 'done' looks like before work starts. None of that requires technical knowledge. It does require a little discipline — and this article will show you exactly what to do.
A clear idea in the business owner's head is not yet a buildable instruction. It has to be written, drawn, tested, and agreed.
Why the idea feels obvious until someone else has to build it
Think about the last time you described your business to a new member of staff. You probably caught yourself saying things like 'well, it depends' and 'we always do it this way' and 'obviously, if the customer is on account, the rules are different.' That expert knowledge is invisible to you precisely because it is so familiar. The same thing happens when you brief a developer.
You say you want a 'dashboard.' In your mind you can see it clearly: the three numbers that matter most, the list of today's jobs, a flag if anything is overdue. Your developer hears 'dashboard' and thinks: how many data points? What time period? Which users can see what? What does 'overdue' mean — one day late, one hour late, past a deadline the customer sets? They will either ask you all of this at once (which feels like an interrogation) or make their best guess (which may well be wrong). Neither outcome is ideal, and neither of you is at fault. The issue is that an idea and a specification are two different things, and only one of them can be handed to a developer.
Why adjectives are not requirements
The briefs developers dread most are full of words like simple, modern, intuitive, and user-friendly. These are preferences, not instructions. They tell the developer how you want users to feel — not what the software must actually do.
'Simple' to a sole trader means large text and a single button per screen. 'Simple' to a product manager means no unnecessary steps. 'Simple' to a developer means few dependencies. All three definitions are legitimate. They may produce completely different software.
Requirements need to describe observable behaviour. 'A customer can check their order status without calling us' is a requirement. 'The interface should feel intuitive' is not. When you find yourself writing an adjective in a brief, pause and ask: what would someone see or do that would prove this is true? Write that down instead.
If you cannot describe what 'done' looks like, your developer cannot build it.
How examples, sample data, and rough sketches reduce misunderstanding
The fastest way to close the gap is to make the abstract concrete. Three tools do most of the work.
- Examples. Instead of describing what the system should do in general, give two or three specific scenarios. 'When a customer orders before 2 pm on a weekday, they should see a delivery date of the following working day. If they order on a Friday afternoon, they should see Tuesday.' That single example tells a developer more than a paragraph of description.
- Sample data. Share a spreadsheet, an old order form, or a photograph of your whiteboard. Real data shows the shape of your information — the fields you use, the edge cases you already handle, the values that are optional versus required.
- Rough sketches. You do not need design skills. A pencil sketch of a screen — boxes for the bits you want, arrows showing what happens when you click — communicates layout and flow far more clearly than words. Take a photo on your phone and send it.
None of this needs to be polished. The goal is shared understanding, not a design document. Rough is fine. Something is always better than nothing.
The developer's role — and where it ends
A good developer will ask questions. They will probe unclear requirements, flag ambiguities, and warn you when something will take longer than you expect. That is part of their job, and you should welcome it.
What a developer cannot do is invent your business rules. They do not know that your trade customers get 30 days to pay while retail customers pay upfront. They do not know that 'active' in your system means something different from 'approved.' When a developer makes assumptions about these things and gets them wrong, it looks like a technical failure. It is actually a communication failure — and the responsibility lies on both sides.
The most productive development relationships treat requirements as a joint exercise. The business owns what needs to happen; the developer owns how to make it happen technically; and both own the conversation in between.
The one-page brief that changes everything
You do not need a 40-page specification. What you do need, before serious development begins, is a one-page brief covering six things.
- The problem. What situation are you improving and why does it matter? ('We manage engineer callouts by phone and whiteboard — jobs get missed and we can't give customers an arrival time.')
- The users. Who will use this software and what do they already know? ('Two office staff booking jobs; eight engineers in the field on mobile; customers checking status online.')
- The actions. What must each type of user be able to do? Write plain sentences. ('An engineer can mark a job started and completed from their phone. A customer can see job status without logging in.')
- The outputs. What does the system produce — reports, notifications, invoices? What does 'done' look like for each action?
- The owner. Name one person on the business side with final say on requirements. Without this, conflicting instructions from multiple stakeholders stall the project.
- The success measure. How will you know, three months after launch, that this worked? ('Customer service calls about order status drop by 40%.')
One page forces clarity. If you cannot fit the core brief on one page, you have not yet decided what you are building — and that is better to discover now than six months into development.
Practical steps to take this week
- Write three user actions. Complete this sentence three times: 'A [type of user] must be able to [specific action] so that [outcome].' These three sentences are the start of your requirements.
- Replace every adjective with a behaviour. Highlight every word like 'simple,' 'fast,' or 'easy' in your brief. For each one, write what someone would observe or do that proves that quality is present.
- Sketch one screen. Choose the most important screen — the one users will see most often — and draw it on paper. Label the elements and note what happens when the main button is pressed.
- Name the decision-maker. Decide who on your team has final authority over what gets built, write their name at the top of the brief, and make sure your developer knows who to ask when requirements are unclear.
Most project problems that look like technical failures are actually communication failures in disguise — and most happen before the first line of code. The single most useful thing you can do right now is write three examples of what users must be able to do in your app. Not aspirations. Not adjectives. Specific, observable actions with a named user, a named task, and a named outcome. That exercise will tell you more about the clarity of your requirements than anything else — and it will give your developer something real to work with.
