Most software, app and website projects that disappoint their buyers were in trouble before anyone wrote a line of code. The brief was a paragraph, three suppliers each quoted a different project, the cheapest quote won, and the gaps turned into variations, delays and arguments about what was “in scope”. This guide explains, in plain words, how South Australian councils, agencies, not-for-profits and small businesses can write a brief that suppliers can price properly, choose a pricing model that matches how certain the scope really is, compare quotes fairly and put the essentials into the contract. It is practical guidance, not legal or procurement advice.
Why quotes for the same project are so different
When quotes for “a new website” or “a booking app” range from a few thousand dollars to many times that, it is rarely because one supplier is greedy and another is generous. Usually each supplier has assumed a different project:
- Different scope. One quote includes content migration, integrations and accessibility testing; another assumes you supply everything ready to load.
- Different quality bar. Automated tests, security hardening, WCAG 2.2 AA conformance and documentation take real effort, and are the first things left out of a low quote.
- Different ownership. Some quotes are for a licence to the supplier’s platform; others hand over the source code and cloud accounts.
- Different running costs. Hosting, support, licences and updates after launch are sometimes in the price, sometimes quoted separately and sometimes not mentioned at all.
- Different risk. A fixed price on a vague scope includes a contingency for the unknowns, or a plan to charge for them later as variations.
A good brief removes most of these differences, so the quotes you receive describe the same project and can be compared on value rather than guesswork.
What a good brief covers
A useful brief is usually a few pages, not a hundred. It describes outcomes and constraints, and leaves the supplier room to propose how to meet them. Cover these sections:
| Section | What to write |
|---|---|
| Background and problem | What happens today, what it costs in staff time, errors or lost customers, and why now. |
| Outcomes | Three to five measurable results, such as “residents can lodge and track a request online without calling” or “quotes go out the same day”. |
| Users | Who will use it: customers or residents, front-counter and field staff, administrators, and people using assistive technology or older phones. |
| Key tasks | The ten or so things users must be able to do, written as short user stories, ranked by priority. |
| Integrations and data | Systems it must connect to (finance, CRM, records, payments, Microsoft 365), data to migrate, and roughly how much. |
| Non-functional requirements | Accessibility, security, privacy, hosting location, availability, performance on a phone, backup and recovery. |
| Constraints | Budget range, key dates, internal people and their availability, and policies or standards that apply. |
| After launch | Who will run it, the support hours you need, and how often you expect changes. |
| What you want back | The format of the response, so every supplier answers the same questions in the same order. |
Two habits make a brief much more useful. First, rank requirements as must, should, could and won’t-have-this-time (often called MoSCoW), so suppliers can show what fits your budget and what would come in a later stage. Second, share your budget range. It feels like giving away your negotiating position, but without it suppliers either over-design or under-design, and you cannot compare their answers.
Write requirements suppliers can price
Vague requirements produce vague quotes. Compare these:
- Vague: “An easy-to-use booking system.” Priceable: “As a customer, I can book, move or cancel an appointment on my phone, choose from available times for three locations, and receive an SMS reminder the day before.”
- Vague: “Must integrate with our finance system.” Priceable: “Paid bookings create an invoice and payment record in Xero within five minutes; refunds create a credit note.”
- Vague: “Must be secure and accessible.” Priceable: “Conforms to WCAG 2.2 AA, tested manually and automatically; multi-factor authentication for all staff accounts; data hosted in Australian cloud regions; daily backups with a tested restore.”
Write a few acceptance criteria for each key task: the conditions that prove it works, including what should happen when something goes wrong. These later become the basis of user acceptance testing and sign-off (see our guide to software testing and UAT for SA projects).
Do not leave the non-functional requirements to the end. Accessibility (our WCAG 2.2 guide lists the common failures), the security baseline (the Essential Eight is a sensible reference point), where data is stored (see Australian data residency) and expected page speed on a phone all affect the design and the price.
Choose a pricing model that matches the uncertainty
There is no single right way to price software work. The right model depends on how well the scope is understood at the time you sign.
| Model | Works well when | Watch out for |
|---|---|---|
| Fixed price | The scope is small, well defined and unlikely to change, such as a brochure website or a clearly specified integration. | A contingency built into the price, and variation charges for anything not written down. |
| Time and materials | The scope will evolve as you learn, and you want to steer priorities sprint by sprint. | Spend can drift without a budget cap, regular reporting and a clear backlog. |
| Capped time and materials | You want flexibility within a firm budget ceiling. | Agree what happens if the cap is reached before the must-haves are done. |
| Staged: discovery, then build | The project is larger or less certain. A short fixed-price discovery produces the scope, design and estimate for the build. | Make sure the discovery outputs are yours to keep and could be taken to another supplier. |
| Subscription or managed service | You are buying a platform or ongoing service rather than a one-off build. | Price rises at renewal, minimum terms, and how you get your data out if you leave. |
For most projects bigger than a simple website, a staged approach is the lowest-risk option for the buyer: you commit a small amount to remove the unknowns, then commit the larger amount with a much better estimate. It also gives you a natural point to stop if the business case no longer stacks up.
Compare quotes fairly
Decide how you will evaluate before the quotes arrive, and write the criteria into the brief. A simple weighted scorecard works for most buyers:
- Understanding of the problem. Did they restate your outcomes in their own words and ask sensible questions?
- Approach and quality. How they will design, test, secure and release the work, and how you will see progress.
- Relevant capability. Evidence of similar work you can verify, and the actual people who will do yours.
- Whole-of-life cost. Build plus three to five years of hosting, licences, support and updates, not the build price alone.
- Risk and ownership. What you own at the end, exit options, and how they handle the risks they identified.
Normalise the quotes before scoring: list what each one includes and excludes against your brief, and add an allowance for anything a supplier left out. Then ask each shortlisted supplier the same follow-up questions, and talk to people they have worked for.
Warning signs worth taking seriously:
- A firm price for a large, vague scope with no assumptions listed
- No mention of testing, accessibility, security or documentation
- Running costs after launch missing or described as “minimal”
- Source code, domains or cloud accounts held only in the supplier’s name
- Pressure to sign quickly, or reluctance to put commitments in writing
- A team you never meet, or one person who is the only one who understands the system
Contract essentials
Councils and agencies usually have standard contract terms and a procurement policy to follow, and businesses often use the supplier’s terms. Whichever applies, check that these points are covered in writing:
- Scope and assumptions. The brief, the supplier’s response and any agreed changes form part of the contract.
- Intellectual property. In Australia, copyright in code generally belongs to whoever wrote it unless they are your employee or a written agreement says otherwise. State whether you own the custom code or receive a licence, and what pre-existing tools or libraries the supplier keeps.
- Accounts and data. Domains, cloud accounts, code repositories and app store listings should be registered to your organisation, with the supplier given access, not the other way round.
- Acceptance. How and when you test, the acceptance criteria, and what happens to defects found before and after sign-off.
- Change control. How changes are requested, estimated and approved before work starts, so there are no surprise variations.
- Warranty and support. A warranty period for defects, then support hours, response times by severity, and the cost of updates and security patches.
- Security and privacy. Where data is hosted, who can access it, how a breach would be reported to you, and how data is returned or deleted at the end.
- Handover and exit. Documentation, credentials, source code and a reasonable transition period if you change supplier (our guide to provider due diligence and exit planning goes further).
- Payment milestones. Tied to working, accepted deliverables rather than dates alone, with a final payment held until acceptance.
For SA councils and agencies
Public sector buyers have extra obligations, but the same brief makes them easier to meet:
- Every SA council must have a procurement policy under the Local Government Act 1999, and agencies work within Treasurerand agencies work within Treasurer’s Instruction 18 and their own procurement rulesrsquo;s Instruction 18 and the SA Government Procurement Framework. Check thresholds, the number of quotes required and any panel arrangements before you go to market (see our guide to SA Government ICT panels).
- Build accessibility, records management, privacy and security requirements into the brief, so suppliers price them rather than treating them as extras.
- Ask for the evaluation information you will need later, such as local industry participation, in a consistent format.
- Plan for probity: the same information to every supplier, questions and answers shared with all, and evaluation notes kept.
The small business version
A small business does not need a formal tender, but a short written brief still saves money:
- Write one or two pages covering the problem, the ten key tasks, your budget range and the date it needs to work by.
- Ask two or three suppliers for a quote against the same brief, including running costs for three years.
- Check first whether configuring or connecting tools you already pay for would solve most of the problem (see custom software vs SaaS for SA small businesses).
- Keep the domain, hosting and code accounts in your business’s name from day one.
- Pay against working, tested features, and test the key tasks yourself before the final invoice.
A one-page brief template
- The problem: what happens today and what it costs.
- Outcomes: three to five measurable results.
- Users: who will use it, including people using assistive technology.
- Key tasks: ten user stories, ranked must, should and could.
- Integrations and data: systems to connect and data to migrate.
- Standards: WCAG 2.2 AA, security baseline, Australian hosting, backup and recovery.
- Budget and dates: range, key deadlines and internal availability.
- After launch: support hours, expected changes and who owns it internally.
- Response format: approach, team, assumptions, inclusions and exclusions, build and running costs, and timeline.
Questions to ask before you sign
- What have you assumed that is not in our brief, and what have you excluded?
- Which requirements drive most of the cost, and what would a smaller first release look like?
- What will hosting, licences, support and updates cost each year after launch?
- How will we see progress, and how often will we get working software to try?
- How is accessibility, security and performance tested, and what evidence will we receive?
- What do we own at the end, and what do we receive at handover?
This article reflects common practice as at late 2026. Procurement rules, thresholds and contract templates differ between organisations and change over time, so check your own policies and take advice before committing.
Talk to an Adelaide team
If you are planning a new system, app or website and want a brief that produces quotes you can actually compare, talk to us about scoping your project or call 0402 401 584. We can start with a short, fixed-price discovery that produces a prioritised scope, estimate and risk list you own and can take to any supplier. Learn more about our application development, website design and managed services.