MOBILE APP PROJECT BRIEF
Prepared with dedev — https://dedev.co/app-brief-template/
Copy, adapt and share this template with any development team.
Write "not sure yet" wherever you need help. A rough brief is enough to start.

1. PRODUCT AND PEOPLE
Working app name:
Who will use it:
Problem they face today:
How they solve it now:
The outcome this app should improve:
Who decides scope and approves work:

2. FIRST USER JOURNEY
Describe one essential journey from start to finish:
Example: A member finds a class, reserves a place and sees a confirmation.
Who else needs access (staff, admins, partners):
What happens when a step fails or the user cancels:

3. FIRST RELEASE AND LATER
Must work at launch (up to three outcomes):
- Outcome 1:
- Outcome 2:
- Outcome 3:
Later, if the first release works:
Explicitly out of scope:
How we will judge whether the first release is useful:

4. PLATFORMS AND DESIGN
iOS / Android / both / not sure:
Countries, languages and accessibility needs:
Design: starting from scratch / wireframes / finished designs:
Reference apps and what is useful about them:
Do users need a website as well as an app:
Devices or operating systems that matter:

5. CONTENT, DATA AND CONNECTIONS
Content supplied by us, and who maintains it:
Existing systems and APIs to connect (links to public documentation):
Who can arrange access to those systems:
Accounts, payments, notifications or location features needed:
What must work offline, and what happens when devices reconnect:
Existing data to migrate and approximate size:
Personal or sensitive data involved and any known requirements:
Do not include passwords, API keys or real customer records in this brief.

6. OPERATIONS
What staff need to manage (content, users, orders, reports):
Who handles support, refunds or content moderation:
Who owns the store, hosting and third-party service accounts:
Expected initial usage and known peaks (state assumptions):
Who maintains the app after launch:

7. BUDGET AND TIMING
Available build budget and currency (range is fine):
Separate allowance for hosting, third-party fees and ongoing operation:
Desired launch date:
Why that date matters; what can move:
Dependencies we must supply (content, designs, access, approvals):

8. ACCEPTANCE AND HANDOVER
For each must-have, describe a check that proves it works:
Example: Given a class with one place left, when a member reserves it,
then they see confirmation and the class has no places left.
Also check cancellations, errors and two people trying at once.
Required handover: source, design files, documentation, accounts, training:
Support expectations and responsibilities after release:
Ownership and licensing questions to confirm in the agreement:

9. QUESTIONS FOR THE DEVELOPMENT TEAM
Assumptions to validate before a fixed proposal:
Highest-risk integration or unknown:
What can be reduced to fit our budget:
Proposed milestones, review process and change handling:
Deliverables, exclusions, recurring costs and release responsibilities:

NEXT STEP
Use this brief to compare proposals against the same scope.
A calculator is a planning aid, not a fixed quote or a record of this brief.
Explore estimates: https://dedev.co/pricing/
Discuss complete mobile app delivery: https://dedev.co/mobile-app-development/
Send a short introduction: https://dedev.co/contact/#project-brief