Software Buying Guides
Before You Brief a Developer: How to Prepare a Custom Software Project
Many software projects that struggle do not fail because of the code. They struggle because the brief was vague, the people who do the work were not consulted, or nobody agreed what "done" meant.
The good news is that most of this can be fixed before you speak to a single developer. You do not need technical knowledge to prepare a strong brief. You need a clear picture of how your business works today and what you want to change.
This guide is for South African MDs, operations managers and IT managers who are about to ask for quotes on a custom system.
1. Start with the problem, not the solution
"We need an app" is a solution. "Our technicians capture job cards on paper and finance only sees them a week later" is a problem. Developers can do much more with the second sentence.
Write one or two paragraphs that answer:
- What is going wrong, or what is too slow, today?
- Who feels the pain: staff, managers, clients or finance?
- What would be noticeably better if it were fixed?
2. Describe how the process actually runs
Walk through the process from start to finish, as it happens in real life rather than as the policy document says. For example: a request arrives, someone logs it, a manager assigns it, a field worker completes it, a supervisor checks it, finance invoices it, and the client pays.
For each step, note who does it, what information they need, what they produce and where it is stored today (paper, spreadsheet, email, WhatsApp or another system). Include the exceptions: rejected work, missing documents, partial payments, cancellations. Exceptions usually drive more of the design than the happy path.
3. List the users and what each may do
Different people need different access. A field worker should not approve their own work, and a client should only see their own records. Make a simple table of user types and what each should be able to view, create, approve or change. This becomes the basis for roles and permissions.
4. Identify the records that matter
What "things" does the business track? Typical examples are customers, jobs, cases, quotes, invoices, assets, learners or vehicles. For each, note the key information and the statuses it moves through. You do not need a database diagram, a plain list is enough.
5. Gather your real documents and data
Collect examples of the forms, spreadsheets, reports and templates you use today, with sensitive data removed if needed. Real examples remove a lot of guesswork and help a developer estimate accurately. If you have existing data to migrate, say roughly how much there is and where it lives.
6. Name the integrations
Does the system need to take payments, send SMS or email, check identity numbers, or connect to accounting software or an existing database? Integrations affect both cost and design, so mention them early. Our guide on integrating payments, SMS and ID checks covers what to think about.
7. Separate must-haves from nice-to-haves
Everything feels essential at the start. Split your list into:
- Must have for launch: the system is not usable without it.
- Should have soon after: valuable, but the business can operate without it for a few weeks.
- Nice to have: ideas worth keeping for later.
A focused first version goes live sooner, gets real feedback, and costs less to change.
8. Be honest about budget and timeline
Developers can propose very different solutions for the same problem depending on budget. Sharing a realistic range helps them suggest what is achievable, instead of either over-scoping or guessing low. Our article on what custom software costs in South Africa explains the main cost drivers.
Also mention any hard deadlines, such as a financial year-end, a school term or a contract start date.
9. Decide who owns the project internally
Someone in your organisation must be available to answer questions, review early versions and make decisions. Projects slow down most when nobody on the client side has the time or authority to decide. Ideally this is someone who understands the process day to day, supported by a manager who can sign off.
10. Think about life after go-live
Ask early about hosting, backups, user support and change requests. Who will host the system? What happens when a user is locked out? How are new features requested and priced? These questions matter as much as the build itself.
What a good developer will do with your brief
A capable software partner will read your brief, ask questions about the exceptions, challenge anything that seems unnecessary, and may suggest that an off-the-shelf product fits better. Be wary of anyone who quotes a fixed price for a complex system without asking questions.
Most serious projects begin with a short discovery phase to confirm users, records, approvals and integrations before full development starts. Your preparation makes that phase faster and cheaper.
A one-page brief template
- Problem: what is wrong today and who it affects.
- Process: the steps, people and exceptions.
- Users: user types and their permissions.
- Records: what you track and its statuses.
- Integrations: payments, SMS, identity, accounting, existing data.
- Priorities: must, should and nice to have.
- Budget and timeline: a realistic range and any hard dates.
- Owner: who decides on your side.
How Cyber Developers can help
Cyber Developers is a South African custom software development company. Our projects follow a simple path: discovery, architecture, UI/UX, development, testing, deployment and support. If you have a brief, even a rough one, send it to us and we will tell you whether to build, adapt or leave it.