# APP DEVELOPMENT PROPOSAL

> **Disclaimer — not legal advice.** This template is provided free of charge, as is and with no warranty of any kind, and using it creates no attorney-client relationship. It is jurisdiction-neutral: you are responsible for adapting it, for your own legal and tax compliance, and for having a qualified professional in your jurisdiction review it before you rely on it. Full terms: https://trycolo.co/terms-of-use

**Prepared for:** [CLIENT CONTACT NAME], [CLIENT COMPANY NAME]
**Prepared by:** [YOUR NAME / STUDIO NAME], [YOUR EMAIL]
**Date:** [DATE]  |  **Proposal ref:** [PROPOSAL NUMBER]  |  **Valid until:** [EXPIRY DATE]
**Working title of the app:** [APP NAME]

## 1. Problem and users

[ONE OR TWO PARAGRAPHS. Example: "Independent [PROFESSION]s in [MARKET] take bookings by phone and messaging apps, which leads to double bookings and no-shows. [APP NAME] lets customers find an available slot, book and pay a deposit in under a minute, and lets the [PROFESSION] manage their week from one screen."]

| User type | What they need to do |
| --- | --- |
| [USER TYPE 1, E.G. CUSTOMER] | [E.G. FIND, BOOK AND PAY FOR A SLOT; RECEIVE REMINDERS] |
| [USER TYPE 2, E.G. PROVIDER] | [E.G. SET AVAILABILITY, SEE BOOKINGS, MARK NO-SHOWS] |
| [USER TYPE 3, E.G. ADMIN] | [E.G. MANAGE PROVIDERS, VIEW REPORTS] |

## 2. Platforms and approach

| Item | Proposal |
| --- | --- |
| Platforms | [iOS / ANDROID / WEB] |
| Approach | [NATIVE / CROSS-PLATFORM FRAMEWORK / PROGRESSIVE WEB APP] |
| Why | [REASON, E.G. ONE CODEBASE FOR BOTH STORES WITHIN BUDGET] |
| Minimum OS versions | [iOS VERSION] / [ANDROID VERSION] / [BROWSERS] |
| Languages | [ENGLISH / OTHER] |

## 3. MVP feature list

| # | User story | Priority | Estimate (days) |
| --- | --- | --- | --- |
| 1 | As a customer, I can create an account with email or [SIGN-IN OPTION] | Must | [NUMBER] |
| 2 | As a customer, I can see a provider's available slots and book one | Must | [NUMBER] |
| 3 | As a customer, I can pay a deposit by card | Must | [NUMBER] |
| 4 | As a provider, I can set weekly availability and block time off | Must | [NUMBER] |
| 5 | As a customer, I receive a reminder [24] hours before my booking | Should | [NUMBER] |
| 6 | As a provider, I can see a weekly summary of bookings and revenue | Should | [NUMBER] |
| 7 | As a customer, I can leave a review after a booking | Could | [NUMBER] |
| 8 | [USER STORY] | [MUST / SHOULD / COULD] | [NUMBER] |

**Proposed MVP:** all "Must" items and [LIST OF "SHOULD" ITEMS].

**Out of scope for the MVP:** offline mode, multiple languages, in-app chat, loyalty programs, web admin beyond [BASIC FUNCTIONS], [OTHER EXCLUSIONS].

## 4. Technical stack and third-party services

| Layer | Proposal |
| --- | --- |
| App framework | [FRAMEWORK] |
| Backend / API | [BACKEND TECHNOLOGY OR SERVICE] |
| Database | [DATABASE] |
| Hosting | [CLOUD PROVIDER], client-owned account |
| Authentication | [SERVICE OR APPROACH] |

| Third-party service | Purpose | Account owner | Estimated running cost |
| --- | --- | --- | --- |
| [PAYMENT PROVIDER] | Card payments | Client | [PROVIDER FEES PER TRANSACTION] |
| [EMAIL / SMS PROVIDER] | Notifications | Client | [CURRENCY] [AMOUNT] / month |
| [MAPS / LOCATION SERVICE] | [PURPOSE] | Client | [CURRENCY] [AMOUNT] / month |
| [ANALYTICS / CRASH REPORTING] | Monitoring | Client | [FREE TIER / AMOUNT] |

Running costs are paid by the client directly to each provider.

## 5. Phases

| Phase | What happens | Output | Duration |
| --- | --- | --- | --- |
| 1. Discovery | Workshops, user flows, feature estimates, technical risks | Confirmed MVP scope and fixed build price | [NUMBER] weeks |
| 2. UX/UI design | Wireframes, clickable prototype, visual design | Approved designs for all MVP screens | [NUMBER] weeks |
| 3. Development | [NUMBER] sprints of [2] weeks with a demo at the end of each | Working builds on test devices | [NUMBER] weeks |
| 4. Testing | QA on listed devices, client acceptance testing | Release candidate | [NUMBER] weeks |
| 5. Release | Store listings, submission, review fixes, production launch | Live app | [NUMBER] weeks |

## 6. Testing and quality

- Testing on [NUMBER] physical devices: [DEVICE LIST], plus simulators for other screen sizes.
- Automated tests for [CORE FLOWS, E.G. BOOKING AND PAYMENT].
- Client acceptance testing period of [5] business days on the release candidate.
- A defect is behavior that does not match the approved designs and user stories.

## 7. Release

- Apps are published under the client's [APPLE DEVELOPER] and [GOOGLE PLAY] accounts. The client creates the accounts and adds me as a team member.
- The client supplies store listing content: app name, description, screenshots approval, privacy policy URL and support contact.
- App store review times and decisions are outside my control. Review feedback is addressed during the warranty period.

## 8. Warranty and support

- **Warranty:** [60] days after launch. I fix defects in delivered work at no charge.
- **Not covered by warranty:** new features, changes to approved designs, operating system or third-party service changes after launch, issues caused by changes made by others.
- **Support plan (optional):** [NUMBER] hours per month for updates, monitoring and minor changes at [CURRENCY] [AMOUNT] / month.

## 9. Budget

| Item | Amount |
| --- | --- |
| Phase 1: Discovery (fixed) | [CURRENCY] [AMOUNT] |
| Phases 2–5: Design, development, testing and release | Estimated [CURRENCY] [LOW] to [CURRENCY] [HIGH] |
| Contingency | [PERCENT]% of build, used only with written approval |

The build estimate becomes a [FIXED PRICE / CAPPED TIME-AND-MATERIALS BUDGET] at the end of discovery. Changes after that are handled through written change requests with a cost and timeline impact.

**Payment milestones**

| Payment | Trigger | Amount |
| --- | --- | --- |
| Discovery fee | On acceptance | [CURRENCY] [AMOUNT] |
| Build deposit | Signing of build price after discovery | [PERCENT]% of build |
| Design approval | End of phase 2 | [PERCENT]% of build |
| Mid-development | After sprint [NUMBER] demo | [PERCENT]% of build |
| Release | App approved and live | [PERCENT]% of build |

All amounts exclude [TAX] where applicable.

## 10. Ownership and code

- On payment in full, the client owns the app's custom source code, designs and store listings.
- I keep ownership of pre-existing tools and libraries I use across projects, and grant the client a permanent license to use them in this app.
- Open-source components are used under their own licenses, listed in the handover documentation.
- Code is kept in a repository owned by [CLIENT / DEVELOPER, TRANSFERRED ON FINAL PAYMENT].
- Full terms are in the attached [SOFTWARE DEVELOPMENT AGREEMENT].

## 11. Acceptance

| Client | Developer |
| --- | --- |
| Signature: ____________________ | Signature: ____________________ |
| Name: [CLIENT SIGNATORY NAME] | Name: [YOUR NAME] |
| Company: [CLIENT LEGAL NAME] | Business: [YOUR BUSINESS NAME] |
| Date: [DATE] | Date: [DATE] |

---

### How to use this template

1. Write features as user stories and estimate every one before you send.
2. Keep the build as a range until discovery ends.
3. Fill the third-party services table so running costs are no surprise.
4. Ask the client to create store and hosting accounts in their own name before development starts.
5. Offer the support plan with the proposal, not after the warranty ends.

*Template provided by Colo (trycolo.co). Not legal advice — review with a qualified professional in your jurisdiction.*