A development quote should break the price into discovery, design, development by area, testing, project management, deployment and post-launch support, with assumptions and exclusions listed. In a healthy quote, design is roughly 10 to 20 percent of the total, testing 10 to 15 percent, and project management 10 to 15 percent. To compare quotes, put them into the same categories, add back anything one has excluded, and compare totals only after that.
Two quotes for the same app can differ by a factor of three and both be honest. They differ because they include different things, assume different scope and structure the numbers differently. This guide explains what you are looking at and how to make quotes comparable before you compare them.
What should a quote contain?
| Section | What it covers | Healthy share of total |
|---|---|---|
| Discovery and planning | Workshops, scope definition, road map, technical planning | 5 to 10 percent, sometimes quoted separately |
| UX and UI design | User flows, wireframes, visual design, clickable prototype | 10 to 20 percent |
| Backend development | Database, API, authentication, business logic, admin panel | 25 to 40 percent |
| Front-end development | Web app, mobile app or both | 20 to 35 percent |
| Integrations | Payments, maps, messaging, third-party and legacy systems | Varies widely, listed per integration |
| Quality assurance | Test planning, automated tests, device testing, bug fixing | 10 to 15 percent |
| Project management | Planning, communication, demos, coordination | 10 to 15 percent |
| Deployment and launch | Cloud setup, app store submission, monitoring, handover | 3 to 5 percent |
| Post-launch support | Bug fixes and adjustments for a defined period | Often a separate line or retainer |
The percentages are guides, not rules. A product heavy on integrations will skew toward that line. A consumer app with a strong brand will spend more on design. What you are checking is that nothing important is missing or implausibly small.
What do the warning signs look like in the numbers?
- Design under 5 percent or absent. Screens will be built without being designed, and rebuilt once users see them.
- Testing absent or folded into development. Developers will test their own work, which is not the same thing, and you will find the bugs.
- Project management absent. Either it is hidden in the rates or nobody is coordinating.
- A single line for "development". No way to see what is included or to compare with another quote.
- Integrations not itemised. They are the most common source of overruns. Each one should be named with its own estimate.
- Hosting and third-party fees presented as included. They are usage-based and paid to other companies. A quote can estimate them but cannot include them.
How do you compare quotes that are structured differently?
- Rebuild each quote into the table above. If a quote does not give you enough detail to do this, ask for it. A company that cannot break its number down has not planned the work.
- List what each quote excludes. Assumptions sections, footnotes and the phrase "not included" are where these live.
- Add the exclusions back. If quote A excludes design and quote B includes it, add a realistic design cost to A. Now you are comparing the same product.
- Check the scope actually matches. One quote may have interpreted "payments" as a single card checkout and another as subscriptions with refunds and payouts. Ask.
- Now compare totals. Along with everything that is not a number: the team, the process, the ownership terms, the references.
What about hourly rates?
Some quotes show hours by role multiplied by rates. This is more transparent, and it invites a mistake: comparing rates instead of totals. A senior team at a higher rate that needs fewer hours frequently costs less than a junior team at a low rate, and the product is better. Compare the total hours and the total price, and ask who the hours belong to. Our comparison of agencies, freelancers and in-house teams shows typical rates by option.
Fixed price or estimate?
Check whether the number is a commitment or an estimate. A fixed price for a defined scope is a commitment. An estimate on a time and materials basis is a forecast that can move. Both are legitimate and they are not comparable with each other without adjustment. See fixed price versus time and materials for the difference.
What is a reasonable total?
Once quotes are comparable, check them against the ranges in what an app costs in 2026. A quote far below the range for your product's complexity has left something out or misunderstood the scope. A quote far above it should come with a clear explanation of why your product is unusual.
Questions to send back with every quote
- Can you break development down by area?
- Which integrations are included, and what does each assume?
- What is excluded?
- Is this a fixed price or an estimate?
- What are the payment milestones?
- What does support cost after launch?
If you have quotes in hand and want help making them comparable, send them over. We will lay them out side by side, and we will tell you if one of them is a better fit for you than we are.
Frequently asked questions
Why is project management charged separately?
Because it is real work done by a real person: planning, running demos, coordinating designers and developers, and keeping you informed. Quotes that omit it either hide it in the rates or do not do it.
Should discovery be in the quote or separate?
Either is fine. Many companies, including 7L, quote a short discovery phase first and then a fixed price for the build, because the build cannot be priced properly until discovery is done.
What does a contingency line mean?
A buffer for the unknowns, typically 10 to 20 percent. It is honest to show it. What matters is whether unused contingency is returned to you or kept, so ask.
Are third-party costs part of the quote?
They should be estimated but they are not the vendor's to charge. Hosting, payment processing, SMS, maps and app store fees are paid by you to those providers. Ask for the estimate so you can budget.
Is a quote in hours more accurate than a lump sum?
Not necessarily. Hours show how the estimate was built, which helps you check it, but the accuracy depends on how well the scope was understood. A lump sum with a detailed scope can be more reliable than hours against a vague one.