Two quotes for the same app can be three times apart, and the cheaper one usually isn’t cheaper. It just leaves things out. So before you compare totals, it’s worth knowing what should an app development quote include, and which missing lines turn into invoices later. This is the checklist we’d use if we were on the buying side of the table.
None of it is exotic. Most of it is the stuff that feels too boring to write down until it’s the subject of an argument.
What should an app development quote include? Start with scope
A quote is only as good as the scope underneath it. Look for:
- Platforms, named. iOS, Android, web, admin panel. Minimum OS versions or browsers. “Mobile app” on its own is not a platform.
- User roles. Customer, staff, admin, vendor, driver. Each role is effectively another app’s worth of permissions and screens. Our taxi dispatch build had separate driver and rider apps plus an admin panel, and each needed its own scope line.
- Features at a testable level. “User profile” can’t be tested. “User can edit name, photo and phone number, and changing the phone number needs OTP verification” can.
- Every third-party integration, by name. Payment gateway, maps, SMS or OTP provider, push notifications, analytics, email, any AI model. Each one is real work, and they aren’t interchangeable. An Indian checkout with UPI, cards and EMI through Razorpay or PayU is a different job from a Stripe checkout for a UK customer.
- The backend. Is it in the quote at all? Where will it be hosted, and on whose account?
- Non-functional requirements. Offline behaviour, languages, accessibility, expected load. If the app has to work offline (Crumb Count, a nutrition app we built, is offline-first with its own sync engine), that changes the architecture and it should change the quote.
Exclusions: what the quote doesn’t cover
A quote with no exclusions list isn’t more generous. It’s ambiguous, and ambiguity gets resolved in whoever’s favour has more leverage at the time. A good quote says plainly what you’re paying for separately or doing yourself, for example:
- Apple Developer Program and Google Play Console fees.
- Running costs: hosting, SMS, maps API usage, email sending, AI model usage, paid SDKs.
- Content entry, product photography, copywriting.
- Privacy policy and terms of service text (developers can tell you what the app collects, but they aren’t your lawyers).
- Ongoing maintenance after the warranty period, including OS updates.
- Marketing, store listing assets, App Store Optimisation.
You may well want some of these from the same team. That’s fine. They should still be priced lines, not assumptions.
Ownership, IP and accounts
This is where cheap quotes save money they shouldn’t. Ask for each of these in writing:
- IP assignment. The contract should transfer ownership of the code and designs to you, ideally as each milestone is paid rather than only at the very end.
- Your repository, from day one. Code pushed to a GitHub, GitLab or Bitbucket organisation you own, with the developer added as a collaborator. Not a zip file at the end.
- Your store accounts. The app is published under your Apple and Google developer accounts. Enrolling as an organisation with Apple needs a D-U-N-S number, which can take a while, so start early.
- Your cloud accounts. AWS, Google Cloud, Firebase or whatever the backend runs on, billed to your card, with the developer granted access.
- Signing keys and certificates stored somewhere you control, with a note of where they are.
- Third-party code disclosed. A list of open-source libraries and paid components, with their licences, so you don’t discover a commercial licence problem during due diligence.
Handoff, warranty and support
The last ten percent of a project is where a lot of quotes go vague. A decent one specifies:
- Documentation: how to set up the project from a clean machine, environment variables, architecture notes, how to release a new build.
- Credential transfer: every account, key and service handed over in a list you can check off.
- A warranty period during which bugs against the agreed scope are fixed at no cost, with a clear line between a bug (it doesn’t do what the scope says) and a change (you’d now like it to do something else).
- Support after that, priced separately: a monthly retainer, an hourly rate, or nothing. Any of those can be fine as long as it’s stated.
Change requests: how the price is allowed to move
Every project changes. Users say surprising things in testing, and a competitor ships something. The question is how changes get priced, and the quote should answer it:
- Changes are requested in writing.
- The developer replies with a price and the effect on the timeline.
- Nothing is built until you approve it.
- The rate for change work is stated up front.
Also check the pricing model itself. On fixed price, the risk of underestimating sits with the developer, which is why they’ll want a tight scope. On time and materials, the risk sits with you, so ask for a weekly report of hours against features and a cap or re-approval point. Either works. A quote that’s neither, a fixed number with a vague scope and “additional work billed hourly”, gives you the downsides of both.
Once you have two or three quotes, line them up against this list rather than against each other. The gaps tell you more than the totals do.
If you’d like someone technical to read a quote before you sign, or to write the scope document that quotes should be based on, that’s the kind of technical consulting orithLabs does. No obligation to build with us afterwards.