The one-page brief
Short on time? Answer these ten lines and send them. It’s enough for a developer to ask good questions and give you a rough range.
Every example on this page is for Walkies, a dog-walking app we made up. It isn’t a real client or product. Its numbers, dates and quotes from owners are invented.
| Line | What to write | Walkies example |
|---|---|---|
| The app in one sentence | What it is and who it’s for | Walkies books a vetted local dog walker in Sydney’s eastern suburbs, often the same day |
| The problem | What’s hard today | Owners who work long hours can’t find a walker they trust at short notice |
| Who uses it | Each type of user | Dog owners, local walkers, and our own team approving walkers |
| What version 1 must do | The few things that make it work | Book a walk, accept a walk, pay by card, get a photo when the walk ends, leave a review |
| If time allows, and later | Nice-to-haves and parked ideas | If time allows: live GPS map. Not in version 1: group walks, vet records |
| Apps we like | The exact part you like | Airtasker for posting a job. Uber for the receipt after a trip |
| How it makes money | Who pays, and how | A 15% fee on each walk |
| Platforms | Phones, web, admin | iOS and Android for owners and walkers. A web admin for us |
| Deadline | A date and why | In both stores by 1 March 2027, for a launch at a pet expo |
| Budget | A range, and whether it includes GST | $80k – $120k ex GST for version 1, plus $20k ex GST for the first year of running and support |
The blank template, ready to copy
Paste these 12 headings into a document. Write a few lines under each. If you can’t answer one yet, write “not sure” and say why. A gap you flag is better than a guess. You can send it to any developer, not just us.
- Summary: what the app is, who’s behind it, new or a rebuild.
- The problem and why now: what’s hard today, how people cope, why they’ll switch.
- Users: each type of user in two lines.
- What success looks like: numbers you want 90 days after launch.
- Version 1 features: numbered user stories, ranked with MoSCoW.
- Not in version 1: what you’re choosing to leave out.
- Apps you like: two or three, and the exact part you like.
- Platforms: iPhone, Android, web, admin panel, offline use.
- Data, systems and compliance: personal information, integrations, rules that apply.
- How it makes money: who pays, how and when.
- Deadline: the date, and what happens on it.
- Budget, contacts and decisions: the range, who signs off, who owns the accounts.
The sections below explain each heading, with prompts and the Walkies example.
The full template: the idea and the people
1. Summary
- What is the app, in one sentence?
- Who is behind it? A startup, an existing business, or a team inside a larger company?
- Is this a new app, or a rebuild of one that exists?
Walkies example: Walkies books vetted dog walkers. We’re two founders with a dog-minding business that has 140 regular clients.
2. The problem and why now
- What is hard, slow or annoying today?
- How do people solve it now? Texts, spreadsheets, a competitor, nothing?
- Why will they switch? What evidence do you have?
Walkies example: Our clients book by text. We turn away about 15 walks a week because we can’t match them fast enough.
3. Users
- Who are the main users? Describe each in two lines.
- Where are they, and what device do they use?
- What do they care about most?
- Any accessibility or language needs?
There’s more on describing users in the next section.
4. What success looks like
- What should be true 90 days after launch?
- Use numbers where you can: bookings, sign-ups, revenue or hours saved.
- Expected usage, like peak times or bookings a day. Mark guesses as guesses.
Walkies example: 300 completed walks a month by June 2027, with at least 40 active walkers.
How to describe users and roles
Users are the kinds of people who use the app. Roles are what each one is allowed to do. Different permissions and workflows add scope, so roles move the price.
Describe each user in two lines: who they are and what they’re trying to get done. Then list what each role can see and do.
| Role | Who | Can do | Can’t do |
|---|---|---|---|
| Owner | Busy dog owner, 25–55, on an iPhone | Add dogs, book and cancel walks, pay, review | See other owners, or walkers’ earnings |
| Walker | Local sole trader with an ABN, often a student | Accept walks, start and end them, upload a photo, see earnings | See an owner’s address before accepting |
| Admin | Our two founders | Approve walkers, refund walks, see all bookings | See full card numbers |
If one person can hold two roles, say so. An owner who is also a walker changes the sign-up flow.
Two sides with payments between them makes this a marketplace. Our marketplace cost guide covers why that costs more.
How to write user stories
A user story is one thing a user needs to do, written from their side. The common format is: As a [type of user], I want to [do something], so that [reason]. Mountain Goat Software calls the format a thinking tool, not a guarantee.
Add acceptance criteria under each story. These are the checks that show a story is done. They help catch different readings of the same story before anyone builds it.
- List each role from the table above.
- For each role, write the things they must do. One story per line.
- Add the “so that”. If you can’t say why, the story may not belong in version 1.
- Add a few acceptance criteria to each Must Have story. Include at least one thing going wrong.
- Number the stories, so you can refer to them on calls and in the quote.
More Walkies examples: As a walker, I want to see requests within 3 km of me, so that I can fill gaps in my day. As an admin, I want to check a walker’s ID and insurance before approving them, so that owners can trust every walker.
How to scope version 1 with MoSCoW
MoSCoW sorts every feature into Must Have, Should Have, Could Have and Won’t Have this time. It’s the prioritisation method used in DSDM, an agile method with guidance from the Agile Business Consortium.
Must Haves are the smallest set that still works. Should Haves are important, but the app is usable without them. Could Haves go first if time runs short. Won’t Haves are agreed out of scope for now.
| Feature | Priority | Why |
|---|---|---|
| Book, accept and cancel a walk | Must | No walks, no app |
| Card payment, charged after the walk | Must | The 15% fee is the business |
| Photo and summary when the walk ends | Must | Our owners say this builds trust |
| Reviews | Must | Quality control for walkers |
| Admin approval of walkers | Must | Safety, and our insurer asks for it |
| Live GPS map during the walk | Should | Valued, but the end photo covers most of the need |
| Repeat bookings | Could | Owners can book each walk separately for now |
| Group walks | Won’t | Different pricing and insurance |
| Vet records | Won’t | Extra document storage and permissions |
DSDM suggests Must Haves take no more than about 60% of the effort, with around 20% in Could Haves. That leaves room for surprises. On a 12-week build, that’s about 7 weeks of the team’s effort on Must Haves.
Live tracking is often what moves an app into a higher budget. Our marketplace guide puts Uber-style apps with live tracking and dispatch at $150k+. That’s why Walkies makes the map a Should, not a Must.
The full template: scope, money and time
5. Version 1 features
- Your numbered user stories, with acceptance criteria on the Must Haves.
- Your MoSCoW list, with a one-line reason for each.
- The full journeys, including cancellations, refunds and two people acting at once.
6. Not in version 1
- The Won’t Haves, so they’re written down and not quoted.
- Anything a competitor has that you’re choosing to skip.
7. Apps you like
- Two or three apps, and the exact part you like in each: a screen, a flow, a tone.
- Any app you dislike, and why. It helps just as much.
8. Platforms
- iPhone, Android, web, or all three? Who uses which?
- What does your team need to manage? Bookings, refunds, content, users? That decides the admin panel.
- Any offline use, like walkers in parks with poor signal?
9. Data, systems and compliance
- What personal information will the app collect? Names, addresses, location, payment details?
- What existing systems must it connect to? A website, CRM, booking or accounting software?
- Is there data to move across from an old app or spreadsheet?
- Does the Privacy Act apply? Most businesses with turnover of $3 million or less are exempt, but there are exceptions, such as some health providers and businesses that trade in personal information. See the OAIC’s small business guidance.
- Even if you’re exempt, both stores need a privacy policy and privacy answers, including what analytics and other SDKs collect. Who writes them?
- Who handles cancellations, refunds, complaints and disputes? Refund terms can’t remove consumer guarantees under the Australian Consumer Law.
- Can users create accounts? Plan a way to request account deletion from inside the app. Google Play also needs a web page for deletion requests.
- Can users post reviews, photos or messages? Plan reporting, blocking and moderation. Apple’s guidelines require these for user-generated content.
10. How it makes money
- Fees, subscriptions, in-app purchases, ads, or part of an existing business?
- Who pays, and when?
This changes the build. Apple’s guideline 3.1.3(e) says physical services used outside the app must be paid another way than in-app purchase, such as Apple Pay or card. Google Play has the same rule. So a dog walk is paid by card through a provider like Stripe, not through Apple’s or Google’s billing.
11. Deadline
- A real date, and what happens on it: a launch event, a season, a funding round.
- If the scope doesn’t fit, which can move: the date, the scope or the budget?
Leave time at the end for store review. Personal Google Play accounts created after 13 November 2023 must run a closed test with at least 12 testers for 14 days in a row, then apply for production access. Our guide to how long an app takes has the stages.
12. Budget, contacts and decisions
- A budget range for version 1, ex GST. The next section explains why.
- Who signs off on design and scope? How fast can they reply?
- Who will own the Apple and Google developer accounts? You should, under your business.
- Who supplies store screenshots, descriptions and test logins for review?
- What do you expect at handover? Code repository, design files, documentation and support.
Apple needs a D-U-N-S number to enrol a company, and a working website on your domain. Sole traders enrol as individuals. Start this early. It can hold up a launch.
How to give a budget
Give the range you have, any hard ceiling, and what each includes. It tells the developer which version of your idea to quote. The same idea can be a $35k web MVP in one city or a $150k app on both stores.
Send every developer the same priorities, exclusions and range. Then compare what each quote assumes and delivers.
- Give a range, not one number. “$80k – $120k” tells the developer where the line is.
- Say if it’s ex GST or GST inclusive. Studios usually quote businesses ex GST.
- Plan cash for the GST on each invoice, even if you can claim it back later. Ask your accountant.
- Keep running costs separate: hosting, app store fees, support and updates. Our maintenance cost guide has typical numbers.
- Say if you have a hard ceiling, and what it includes.
| Budget (AUD, ex GST) | Typical scope at Apptractive | Time |
|---|---|---|
| $25k – $50k | One core feature, sign-in and a simple backend. Or a web MVP to test demand | 1–2 months |
| $50k – $100k | Accounts, payments, an admin panel, iOS and Android. A lean marketplace app on both stores starts near the top | 3–4 months |
| $100k+ | Larger marketplaces, live tracking, real-time features or heavy AI | 5+ months |
Walkies example, assuming every cost attracts 10% GST: the founders have $154k in cash for the first year. They keep $22k for running and support, which is $20k plus GST. That leaves $132k, which is $120k ex GST plus $12k GST. So the brief says “$80k – $120k ex GST”.
Ranges match our app cost guide.
What to attach, and what to leave out
Attach if you have it
- Sketches, wireframes or a clickable prototype. Photos of a whiteboard are fine.
- Your brand: logo, colours, fonts and any style guide.
- Research: customer interviews, survey results, a waitlist count.
- Screenshots of the apps you mention in section 7.
- Sample forms or spreadsheets you use today, with customer details removed. They show the real data.
- Names and documentation links for systems the app must connect to, and who can arrange access later.
- For a rebuild: the current app’s store links, analytics and any known problems.
Never put passwords, API keys or real customer records in a brief.
Leave out
- The technology, unless you have a reason or a rule to follow. Then say so.
- Pixel-perfect screens. Attach any designs you have and say what can change.
- Every small edge case. Include the ones that could change the scope, and list open questions for the workshop.
- Long market analysis. One paragraph on why now is enough.
Do you need an NDA before sharing your brief?
You can ask for one, and Apptractive will sign it. But know what an NDA does and doesn’t protect.
In Australia, ideas alone aren’t protected by copyright. IP Australia says so plainly: copyright protects the original way an idea is expressed, not the idea. So “an app for booking dog walkers” isn’t protected. Your original written brief and designs can be, automatically.
- An NDA is a contract to keep shared information confidential. IP Australia has a free NDA generator.
- Paying a developer doesn’t automatically give you the copyright. Agree in writing who owns the code and designs they create, and which existing parts are licensed to you.
- If your idea includes a new invention, keep it confidential until you’ve spoken to a patent attorney. Telling people publicly first can affect a patent.
- A registered trade mark protects your brand for the goods and services it’s registered for. An original logo may also be covered by copyright.
- Control your own app store, domain and cloud accounts from day one.
This is general information, not legal advice. Talk to a lawyer about your situation. Our guide to choosing an app developer covers the contract terms to check.
What happens after you send it?
- We read the brief and reply with questions and a rough range.
- If it looks like a fit, we run a requirements workshop. We list every screen, role and story.
- You get a quote for the full build.
- Design starts once you’ve agreed the scope.
We’re an Australian team in North Bondi. Send your brief through our free estimate form, or see how we work.
Common questions
What should an app brief include?
A summary, the problem, the users and their roles, what success looks like, what version 1 must do, what is left out, apps you like, platforms, data and integrations, how it makes money, the deadline, a budget range and who makes decisions. Flag anything you are unsure about.
How long should an app brief be, and do I need a technical spec?
One page can be enough for a rough range. Two to four pages, with numbered user stories and priorities, gets you a tighter one. You do not need a technical spec. A good developer writes it with you in a requirements workshop.
Can I get a fixed quote from an app brief?
Usually you get a range first. A fixed quote needs the open questions answered, such as integrations, edge cases and who does what at launch. That normally takes a requirements workshop.
What is the difference between an app brief and a requirements document?
A brief explains the problem, users, priorities, budget and deadline in your own words. A requirements document describes the agreed behaviour, rules and acceptance criteria in detail. You write the brief. The developer usually writes the requirements document with you.
Should I share my budget with an app developer?
Yes. A range tells the developer which version of your idea to quote. Send every developer the same range and priorities, then compare what each quote includes.
Will Apptractive sign an NDA before reading my brief?
Yes. Ask when you get in touch and we will sign one before you send the details.
Can someone steal my app idea?
An idea on its own is not protected by copyright in Australia. Your original brief and designs can be. An NDA, a contract that says who owns the work, and control of your own accounts are the practical protections.
Can I use AI to write my app brief?
Yes, as a first draft. Then check every line against what you actually know, and mark guesses as guesses. Check the AI tool’s data terms before pasting in anything confidential.
Sources
- IP Australia: Copyright infringement (ideas alone are not protected)
- IP Australia: Non-disclosure agreements
- business.gov.au: Copyright
- Agile Business Consortium: MoSCoW prioritisation
- Mountain Goat Software: User stories
- OAIC: Small business and the Privacy Act
- Apple: App Review Guidelines
- Apple: Enrolling in the Apple Developer Program
- Google Play: Payments policy
- Google Play: Testing requirements for new personal accounts
- Google Play: Account deletion requirements