How to Brief a Software Developer Without Saying "Make It Like Facebook"
Every week, somewhere in Nairobi, a version of this conversation happens when a business owner is hiring a software developer in Kenya for the first time.
Client: We want an app.
Developer: Sawa. What should it do?
Client: Everything. Like Facebook. But for our chama. And M-Pesa. And maybe it can do our accounts.
Developer: Okay. Who will use it?
Client: Everybody.
Developer: And when do you need it?
Client: Ideally yesterday, but we are reasonable people, so next Friday.
If this conversation sounds familiar, you are not alone, and you are not a bad client. Most business owners have never had to describe software before. It is a bit like describing a house to a builder when you have only ever lived in houses, never built one. The good news is that a clear brief is not technical at all. It is mostly about your business, which you already know better than anyone.
Describe the problem, not the solution
The most useful thing you can tell a developer is what is going wrong today. "Members of our chama keep disputing who has paid, and our treasurer Nyambura spends every Sunday evening reconciling M-Pesa messages with a notebook" is gold. A developer can work with that. "Make it like Facebook" tells them almost nothing, because Facebook does a thousand things and you probably need three of them.
Resist the urge to design screens in your head before you have explained the pain. You might end up with a beautiful app that solves the wrong problem, which is a very expensive way to learn a lesson.
What to include when hiring a software developer
The problem you want solved, in plain language
Who the users are, such as members, the treasurer, customers or staff
What those people do today, step by step, including the paper and WhatsApp parts
The must-haves for a first version, separated from the nice-to-haves
Anything it must connect to, like a paybill, your accounting package or an existing website
Your rough budget range and any real deadline, with the reason for it
Who in your organisation makes the final decisions
That last point saves more projects than people realise. If three directors each give different feedback, the developer will build a confused product that pleases nobody. Pick one person to speak for the business.
Write little stories about your users
A simple trick is to describe what each type of user needs to do, in one sentence each. For example: "As a chama member, I want to see my total contributions so I do not have to ask the treasurer." Or: "As the treasurer, I want payments to be recorded automatically so my Sundays are free." Ten or fifteen of these sentences paint a clearer picture than a forty-page document full of words like "robust" and "seamless".
It is fine to point at other apps, but be specific
Examples help, as long as you say what exactly you like. "I like how my bank app shows a list of recent transactions with dates and amounts" is useful. "I like Instagram" is not, unless you can explain whether it is the photos, the feed, the simplicity or the fact that your niece is on it.
Equally useful is what you dislike. "Our current system asks for the same information on three different screens" tells a developer exactly what to avoid.
Talk about money and time honestly
Many clients hide their budget, hoping to get a bargain. In practice, this just means the developer guesses, and the first proposal is either far too big or far too small. Sharing a realistic range lets them suggest what is achievable: perhaps a lean first version now, with extra features added once you see how people actually use it.
Be honest about deadlines too. If you need something for the annual general meeting in March, say so. If "next Friday" was just a figure of speech, admit it before someone cancels their weekend.
After the brief, stay involved
Ask to see work early and often, even when it looks unfinished. Test it with real users, not just yourself. Reply to questions promptly instead of leaving them for a week, because every unanswered question is a small pause in your project. A brief is the start of a conversation, not a parcel you drop off and collect later.
When your brief is ready, the next step is a conversation. Talk to Philsoft about turning it into a sensible first version, or read how our custom software services work. And if you absolutely must say "like Facebook", at least add which part. Your chama treasurer will thank you.