# App development brief template: screens, roles and integrations
Source page: https://dfygames.com/guides/app-brief-template (published 2026-10-19, updated 2026-10-19) · Topic: Buying an app
Cite as: DFY Games, "App development brief template: screens, roles and integrations", updated 2026-10-19, https://dfygames.com/guides/app-brief-template

**Quick answer:** A good app development brief names the problem, the types of user (roles), every screen each role needs, the outside systems the app connects to, and the personal data it stores. Fill in the worksheets below and a developer can return a written scope and quote instead of a guess.

- Core worksheets: Roles, screens, integrations, data
- Time to fill in: An hour for a focused app
- Worked example: Single-location booking app
- DFY Games quote form: Twelve questions, about 4 minutes

Downloads: [App development brief template](https://dfygames.com/templates/app-brief-template.md)

## 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](https://dfygames.com/apps).

## 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](https://dfygames.com/guides/booking-build-vs-buy) 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) |

> Can a role wait?: If staff could use the calendar they already have for the first months, the app drops from three roles to two. Mark each role as launch or later.

## 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](https://dfygames.com/guides/booking-app-integrations) 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](https://dfygames.com/apps/quote) 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](https://dfygames.com/guides/mobile-app-development-cost).

## FAQ

**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.

## Related
- Service page: [Custom mobile app development](https://dfygames.com/apps)
- [Mobile app development cost: a practical scope guide](https://dfygames.com/guides/mobile-app-development-cost)
- [Mobile game design document template: what to put in your brief](https://dfygames.com/guides/mobile-game-brief-template)

---
DFY Games (Done For You Games), https://dfygames.com. More guides: https://dfygames.com/guides · Index for AI assistants: https://dfygames.com/llms.txt