What a brief does for your quote
Two developers given "a booking app for my gym" will price two different products. One imagines a public booking page; the other imagines memberships, staff schedules, payments and a coach app. The brief removes that guesswork. It does not need technical language. It needs the people, the screens and the systems, listed plainly.
The worksheets below use a single-location booking app as the example. Replace the rows with your own; the structure works for any custom app.
Start with the problem and the people
Opening section of the brief
- The problem in two sentences: what goes wrong today, and for whom
- The current workaround (spreadsheet, group chat, paper forms, an existing tool)
- Who uses the app: customers, members, employees or the general public
- Platforms: iPhone, iPad, Android, and whether staff need a web admin
- What success looks like three months after launch, in one measurable line
- Why existing software does not solve it (have you tried it?)
Be honest about that last line. If an off-the-shelf tool covers 90% of the job, renting it is usually cheaper than building. Our booking build vs buy guide shows how to decide for one common case.
Roles worksheet
Each role is a separate set of flows and permissions, so roles shape the cost more than any other line in the brief.
| Role | Who they are | What they must be able to do | What they must never see |
|---|---|---|---|
| Client | Members of the public booking a service | Browse services, book and pay a deposit, reschedule, cancel, delete their account | Other clients' bookings or contact details |
| Staff | Stylists or practitioners | See their own day, mark no-shows, block time off | Payment settings, other staff's earnings |
| Owner | The business owner | Edit services and prices, see all bookings, export reports | Clients' full card details (held by the payment provider) |
Screens worksheet
| Screen | Role | Purpose | Data shown or entered | Launch or later |
|---|---|---|---|---|
| Welcome | Client | Explain the app, start sign-in | None | Launch |
| Sign in | Client | Create account or log in | Email or phone | Launch |
| Service list | Client | Choose a service | Names, durations, prices | Launch |
| Slot picker | Client | Pick staff and time | Live availability | Launch |
| Deposit | Client | Hold the slot with a payment | Card via payment provider | Launch |
| Confirmation | Client | Show booking and add to calendar | Booking details | Launch |
| My bookings | Client | Reschedule or cancel | Upcoming and past bookings | Launch |
| Profile | Client | Edit details, delete account | Name, contact, preferences | Launch |
| Reviews | Client | Rate a past visit | Rating and comment | Later |
| Loyalty card | Client | Track visits toward a reward | Visit count | Later |
Repeat the table for each role. Count only the rows marked launch when you compare quotes, and keep the later rows as your roadmap.
Integrations worksheet
| System | Why it is needed | Data direction | Account owner | Launch or later |
|---|---|---|---|---|
| Payment provider | Deposits and refunds | App sends charges; provider sends status | Business | Launch |
| Calendar | Staff see bookings where they already work | Two-way sync | Each staff member | Launch |
| Email or SMS service | Confirmations and 24-hour reminders | App sends | Business | Launch |
| CRM | Marketing follow-ups | App sends new clients | Business | Later |
| Existing database | Import past clients | One-time import | Business | Later |
"Two-way sync" is the phrase to look for: it is much more work than sending data one way. The booking integrations guide goes deeper on calendars and payments.
Data and compliance
List every kind of personal data the app collects: basic profiles, location, health, financial, children's or biometric data. Each sensitive category adds safeguards, store disclosures and often legal review. Rules such as GDPR in Europe and COPPA for children in the US may apply depending on who your users are. A developer can build to a checklist, but the legal call belongs to a lawyer, so note in the brief whether you already have one.
Constraints, existing material and sending the brief
Last section of the brief
- What already exists: brand guide, wireframes, a clickable prototype or an existing app
- Timing: flexible, a rough month, or a fixed date (and why)
- Budget range, or a note that you want guidance
- What you expect next: more users, more integrations, a second platform
- Who signs off decisions on your side
DFY Games' app quote form asks the same questions in twelve short steps. Paste from your worksheets and you will get either a short clarification or a written scope with assumptions, timeline and quote. Apps are always quoted individually; for what drives that number, see the mobile app development cost guide.
Frequently asked questions
What should an app development brief include?
The problem, the user roles, a screen list per role, the integrations, the personal data collected, existing material, timing and budget.
How detailed does an app brief need to be?
Detailed enough that every screen and integration is named and marked launch or later. Visual design and technical choices can be left to the developer.
Do I need wireframes before asking for a quote?
No. A screen list with the purpose and data for each screen is enough for a first quote; wireframes help but are optional.
Why do integrations matter so much in a brief?
Each external system is its own build and test surface, and two-way syncs cost more than one-way data sends. Listing them avoids the most common quote surprises.
Can I use this template for a game?
Games need a different brief built around the core loop. Use the mobile game brief template for game projects.
Written and reviewed by the DFY Games team. Published ; facts checked . Prices and store rules change: check the linked sources before you rely on a figure.