A working document for non-technical founders
Fill this in, send it to your developer, and agree what “done” means before any money moves.
Draft v0.3
Most advice tells you to write a detailed spec before you hire a developer. That advice is not wrong, but it misses where projects actually break.
Projects rarely fail because a founder was careless. They fail because of things the founder never mentioned — not out of laziness, but because those things were so obvious to them that saying them out loud felt unnecessary. Of course it connects to the till. Of course it prints a receipt. Of course it produces a proper invoice. That was never a hidden requirement. It was simply the job, and the developer had no way of knowing.
A blank form does not solve this. You cannot write down an assumption you do not know you are making. So this document does three things instead.
That third one is the most important page in here. Most disputes between founders and developers are not about quality. They are about the finish line, which nobody agreed on, and which each side quietly assumed was somewhere different.
The bar is comprehension, not polish. You do not need Figma, diagrams, or the right vocabulary. A photo of a sketch on the back of an envelope with a caption in plain English is worth more than a beautiful document that leaves the important questions unanswered. It only has to be understandable to the developer.
You do not need to know how any of it works. Nothing here asks about databases, frameworks, or hosting. That is the developer's job. Your job is to describe what happens, for whom, and how you would know it was working. Nobody else can do that part.
Expect this to take an evening, and expect to come back to it once. That is still faster than four months of building the wrong thing.
You are going to write a plan. This section is where the material for it comes from.
The expensive parts of a software project are almost never the things a founder forgot to mention. They are the things so obvious that mentioning them never occurred to them — the till it connects to, the receipt it prints, the invoice format the accountant needs. Those do not surface when you describe your idea, because in your head they are not features. They are just the job.
They do surface when you describe a real day, and they surface faster still when a developer looks at your actual spreadsheet. Every column in it is either a requirement you would not have written down, or something you asked for but never actually use.
So describe the day first and attach the real files. Sections 3 to 6 are largely already contained in what you write here — you will be copying out of it rather than starting from nothing.
Pick a normal, busy day — not your best one and not a disaster. Describe what actually happens now, in order, in plain sentences. A developer reading this should be able to picture your Tuesday.
First thing in the morning, I…
When a customer, order, or enquiry comes in, it arrives by… and then I…
During the day I have to…
At the end of the day I…
Once a week or once a month I…
The part of this that wastes the most time is…
The part where things most often go wrong is…
This is the step that saves the most money, and the one most people skip. List every place you currently keep information — then attach the real thing, with the real messy data in it. Not a description of it.
Software and tools I already pay forInclude anything the new system may have to work alongside.
A developer looking at your real spreadsheet will see six columns you would never have thought to mention. Some of those columns are half the project. They will also spot two or three things you asked for that the spreadsheet proves you never actually use — and those get cut before you pay for them. Half of a typical wishlist dies at this step. That is the point.
Answer every line, including the ones that seem obviously not applicable. These are the questions that turn a two-line brief into a four-month project, and every one is cheaper to answer now than to discover later.
If you catch yourself thinking well, obviously at any of these — that is exactly the line to write a full answer on.
Does it need to take payment? If so, how, and who holds the money?
Does it produce an invoice or receipt? Must it look a particular way, or meet a tax rule?
Does it print anything to a physical printer?
Does it talk to equipment you already own — a till, card reader, scanner?
Does it talk to software you already pay for — accounting, email, calendar, stock?
Does it handle tax, VAT, GST, or anything else a government requires?
Do several people log in? Do they see different things?
Does it work on a phone? Which parts, and for whom?
Does it need to work when the internet is down or slow?
Does it send emails, texts, or notifications? To whom, when, saying what?
More than one language, currency, or time zone?
Must records be kept for a legal or accounting reason? For how long?
Can you export your own data out of it?
What happens when someone asks you to delete their personal information?
Anything else that is completely obvious to you about how this works, that a stranger would not know
List every type of person who touches the software. Include the boring ones — the admin who fixes things when they go wrong is a real user, and forgetting them is a common and expensive omission. Most projects have two or three.
User type
What they are trying to get done
What they do today instead
What they must be able to do in the software
What they must not be able to do or seeThis is the line that stops staff seeing each other's pay, or one customer seeing another's details. Do not leave it blank.
User type: Dog groomer — the customer paying me.
Trying to get done: Fill their week with appointments without spending evenings returning calls.
Today: Answering the phone mid-groom, writing bookings in a paper diary.
Must be able to: Set working hours, see upcoming bookings, move or cancel one, be told when a new booking arrives.
Must not: See another groomer's bookings if we ever add a second one.
Copy this block for each user type.
Everything a user sees is a screen. Everything they do happens on one. Most small projects have between four and twelve — more than twenty means your first version is too big, so see Section 7.
Sketch each screen on paper and photograph it, or fill in the written form below. Both work equally well. What does not work is skipping this.
Screen name
Who sees it, and how they got here
What is on itEverything visible — text, lists, images, buttons, fields.
What they can doEvery button and field, and what happens after: “when they ___, then ___”.
What it looks like when it is emptyA brand new user, before there is any data.
What it looks like when something goes wrong
Screen name: Booking page
Who and how: Customers, not logged in. Tapped the link in our Instagram bio.
What is on it: Business name and photo; a calendar of the next four weeks; available slots as tappable buttons; unavailable days greyed out; a short note the owner can edit.
What they can do: When they tap an available slot, they go to the details screen and that slot is held for ten minutes. When they tap a greyed-out day, nothing happens. When they tap the phone number, their phone dials it.
When empty: If no availability has been set at all, show “Not currently taking online bookings — call us on [number]” instead of the calendar.
When it goes wrong: If someone else takes the slot while this customer is filling in their details, say so plainly and show the calendar again with that slot gone.
Software remembers things between visits. Describe what, in plain English. No tables, no technical terms.
Thing
What we know about it
Who can see it
Who can change it
Can it be deleted, and what happens to related things if it is
Thing: A booking.
What we know: Date and time, staff member, customer name, phone, email, service, price, notes, and whether it is confirmed, cancelled, or completed.
Who can see it: Staff see all bookings. Customers see only their own, through a link in their confirmation email.
Who can change it: Staff can change anything. Customers can cancel, but only more than 24 hours ahead.
If deleted: Bookings are never deleted, only marked cancelled — the history is needed for the accounts.
That last line is invisible to a developer and obvious to you. Those are the lines worth writing down.
Every rule you leave out is a decision your developer makes without you. Write the answers as full sentences: “A customer cannot book less than two hours ahead.” “If a payment fails, hold the slot for fifteen minutes and email a link to retry.”
What happens when someone not logged in tries to see something private?
What happens when two people do the same thing at the same moment?
What are the limits? Minimum notice, maximum per day, one account per email, file sizes?
What is required, and what is optional?
What happens when a payment fails?
Who gets notified, when, and what does the message say?
What can be undone, by whom, and for how long?
What must never happen under any circumstances?Double bookings, one customer seeing another's data, being charged twice.
What happens if their connection drops halfway through?
Write down explicitly what is not in this version. This single section prevents more arguments than any other, because it turns “I assumed that was included” into a decision on paper.
Not in version one
Possibly in a later version
No online payment — customers pay in person as they do now. Website only, no mobile app. Email only, no SMS reminders. One staff member, not a team. No customer accounts or passwords; bookings are managed through an emailed link.
If this list is empty, you have not thought about scope, and your quote will be wrong.
This is the most important section in this document.
A spec describes what gets built. It does not say how either of you will know it is finished. That gap is where most disputes actually live: the work is delivered, the founder says it is not done, the developer says it matches what was agreed — and both are telling the truth.
Fix it by writing the finish line down in advance, in a form you could test yourself. For each main piece of the build, write one sentence describing something you could personally sit down and do that would prove it works.
“The booking system works.”
“A customer on their phone can pick a free slot, enter their details, and get a confirmation email within a minute — and that slot immediately disappears for everyone else.”
“Admin panel is finished.”
“I can log in, change next Thursday's opening hours, and see the booking page update — without asking anyone for help.”
Feature
It is done when…
Feature
It is done when…
Write these before you agree a price. Send them over and ask directly: is this the same list you are quoting against? If any answer surprises you, you have just avoided the argument.
Anything visual has no natural end point. “Make it pop” cannot be tested, cannot be finished, and will consume as many rounds as you allow it to. Give it a boundary instead:
Two or three websites whose look I like, and what specifically I like about each
How many rounds of visual changes are included
Who has the final say when we disagree
How the work is broken into stages, and what is paid at each
What happens if something takes longer than expected
What counts as a bug to be fixed free, versus a change to be paid forWorth a conversation even if you write nothing else down.
Who owns the finished code, and whose account it lives in
Who fixes it when it breaks after launch, and on what terms
Deadline, and the real reason for itA trade show, a lease, a season. “As soon as possible” tells a developer nothing.
Budget rangeSay it. A developer who knows your number will tell you what fits inside it. One who doesn't will quote for everything you described, and you will both have wasted the conversation.
Who decidesOne named person who can answer questions and approve work. If it is really a committee, say so now.
How fast you can answer questionsBe honest. A developer waiting three days for an answer is a stalled project.
Whatever two developers would build differently is the part you have not specified — and it is the part you will pay to have built twice.
A developer working from this should return a quote with a breakdown, a timeline, and questions. If they send a single number and no questions, be careful: either they have not read it, or they intend to interpret the gaps in whichever direction is cheapest.
Questions are the sign of someone who is going to build the thing you actually described.