Writing the brief for a SaaS

A brief isn't a document written to look serious. It's the list of what will be delivered, and it's that list which sets the price and the deadline. Without it, a quote is an estimate; with it, it's a commitment.

• Who uses the product — one role per line: the customer, you, a moderator, each with what they come for.
• The screens, one by one — what you see, what you do, and which need it answers.
• What is paid for — subscription, one-off purchase, credits, and by which means: card, Mobile Money, transfer.
• What runs on its own — emails, notifications, reminders, and when they go out.
• Security and moderation — what must hold from day one, no exceptions.
• What will wait — written down, so it isn't mistaken for what was promised.

• The technology — it follows from the rest, and it isn't yours to choose.
• Colours and exact wording — they come while building, once the product runs. A brief that describes buttons is already wrong the day it's finished.

On the first call, you tell me about the project and I tell you what's feasible. In the first week we write it together, screen by screen — often in one or two sessions. You then get a deadline and a price, in writing.

On Studlas, the founder knew what he hadn't had as a student: someone to read the paperwork, explain the steps, put him in touch with people who had been through it. The brief came out of that sentence — the assistant, the mentors, the city groups — and the build order with it.

What we discover along the way is fixed along the way: that's what the weekly check-in is for. What changes the product — one more role, one more payment method — is discussed again, with a new deadline in writing. A brief doesn't stop you changing your mind; it stops you doing it without knowing.