Business Systems
How to Brief a Software Developer and Get an Accurate Quote
What to prepare before asking for a quote on a website, system or app: goals, users, scope, integrations and budget, plus a simple brief template.
The quality of a quote depends on the quality of the question. A vague request such as "I need a system to manage my business" gets vague answers, wide price ranges and misunderstandings that surface halfway through the project. A clear brief fixes that. It does not need to be technical, just specific.
Why a brief matters
- Quotes become comparable. Every supplier prices the same thing.
- Fewer surprises. Gaps are discovered on paper, not in expensive rework.
- Faster start. The developer spends less time guessing and more time building.
- Better decisions. Writing the brief forces you to think through what you really need.
The brief, section by section
1. About your business
Two or three sentences: what you do, who your customers are and how big the team is. This gives the developer context for design and scale decisions.
2. The problem
Describe the pain in plain language. Be concrete about what is going wrong today.
- "Quotes take two days because pricing is in three spreadsheets."
- "Clients phone daily for order updates."
- "We lose bookings when two staff capture the same slot."
Problems are more useful than solutions at this stage. Sometimes a developer will propose something better than the system you imagined.
3. Goals and success measures
What should be different once this exists? Where possible, use measurable outcomes:
- Reduce quote turnaround from two days to two hours.
- Cut status calls by half.
- Eliminate double-bookings.
- Let clients pay invoices online.
These keep everyone focused and make it possible to judge whether the project worked.
4. Users and roles
List who will use the system and what each person needs to do.
| Role | Needs to do |
|---|---|
| Sales staff | Create and send quotes, see customer history |
| Manager | Approve discounts, view reports |
| Client | Log in, view orders, pay invoices |
| Administrator | Manage users and settings |
Roles drive permissions, screens and security.
5. Key features, in priority order
Split features into three buckets:
- Must have: the system is useless without them.
- Should have: important, but you can launch without them.
- Nice to have: for later.
Being honest about priorities is the best way to control cost. Many projects succeed by launching a focused first version and growing from there.
6. Current process and examples
Describe how the work flows today, including forms, spreadsheets and documents. Attach samples: the spreadsheet, the invoice template, the paper form. Real examples prevent weeks of confusion.
7. Integrations
List the other systems this must work with:
- Accounting software.
- Payment gateway.
- Email and calendar.
- Courier or logistics tools.
- Existing websites or databases.
Name the exact products, since integration effort varies widely. See connecting accounting software to your store and CRM for what to consider.
8. Data and security needs
- What sensitive or personal information will it hold?
- Who must not see what?
- Are there legal or industry requirements? See POPIA and your business website.
- Do you need an audit trail of changes?
- Do you have existing data to import?
9. Look, feel and devices
Share websites or apps you like and say why. Note which devices matter most: desktop in the office, phones in the field or both. Provide logos and brand guidelines if you have them.
10. Timeline and constraints
Do you have a hard deadline, such as a seasonal peak or a campaign date? What can wait? Mention staff availability for testing and feedback, because slow feedback is a common cause of delays.
11. Budget
Share a range. This is not a negotiating weakness. Developers can then suggest the best option within your means rather than quoting for a system you cannot afford. For a sense of scale on website projects, read what a business website costs in South Africa.
12. Ongoing needs
Ask yourself who will host, update, secure and support the system after launch. Request pricing for these as well as the build.
Questions to ask each supplier
- Have you built something similar? Can I speak to a past client?
- Who will actually do the work?
- How do you handle changes to scope, and how are they priced?
- Will I own the source code and the data?
- What does support cost after launch?
- How will we communicate, and how often will I see progress?
- How do you test, and how do you handle bugs after launch?
How to compare responses
Look beyond the total.
- Does the proposal show they understood your problem?
- Is the scope itemised and clear about what is excluded?
- Is the timeline realistic with milestones?
- Are payments linked to deliverables?
- Do they raise sensible questions or risks? The suppliers who push back thoughtfully are often the ones you want.
Be wary of a quote that is far below the others without explanation. Hidden scope gaps usually reappear as change requests later.
A one-page brief template
Business: what we do, who we serve Problem: what hurts today Goals: three measurable outcomes Users: roles and what they do Must-haves: the essential features Later: nice-to-have features Integrations: systems it must connect to Data and security: sensitive data, access rules Timeline: key dates Budget: range After launch: hosting, support, ownership
Fill that in and you are ahead of most clients. If you are still deciding whether to build or buy, read custom software vs off-the-shelf first.