Two business owners can send out the same three words — “we need an app” — and receive quotes that bear no resemblance to each other. Not because one supplier is honest and the other isn’t, but because they’ve each imagined a different product.
One pictured a single-screen tool for eight staff members. The other pictured customer accounts, card payments and a dashboard for the office to manage it all. Both are apps. They are not the same job.
A quote is only as meaningful as the scope behind it. If nobody has written down what’s being built, the number is a guess — and quotes that vary wildly are usually a sign that the brief left too much room for interpretation.
This is what a useful quote contains, what genuinely drives the cost, and how to prepare so the figures you receive are comparable.
What an app quote should cover
A proposal worth comparing describes the work, not just the price. Look for:
Discovery. Turning your requirements into a definition — screens, user journeys, data, integrations. Some suppliers include this; some quote it separately; some skip it and absorb the risk in the price.
Design. Screen layouts and how the app looks and behaves. Whether that means a full design process or applying standard platform components should be stated.
Development. The app itself, on the platforms named.
Backend work, where needed. Many apps need a server, a database and an interface between them and the app. Some don’t. Whether it’s in scope changes the figure substantially.
Testing. On real devices, across screen sizes and operating system versions.
Launch. Store listings, screenshots, privacy declarations and submission.
Handover. What you receive at the end, and when.
Then the two things people skim past and shouldn’t:
Assumptions. What the supplier has taken as given. “Client supplies all written content.” “One round of design revisions.” “Existing API is documented and available.” If an assumption turns out to be wrong, the price changes — so it’s worth reading these as carefully as the deliverables.
Exclusions. What isn’t included. App store fees, ongoing hosting, content writing, photography, post-launch support. A quote with a clear exclusions list is easier to trust than one without.
What actually drives the cost
Rather than a long list of features, it helps to think in groups.
Platforms and reach. Android only, iOS only, or both. Two native apps means two builds; a cross-platform framework shares much of the work. Neither is automatically right, and the choice depends on what your app does — we’ve covered how that decision gets made separately.
Accounts and roles. An app anyone can open is far simpler than one with logins. Add roles — customer, staff, manager, administrator — and you’ve added permission rules, and every screen now has to behave correctly for each of them.
Backend and data. Where information lives. An app that only displays fixed content needs very little behind it. An app storing customer records needs a server, a database, an API, authentication, backups and a plan for growth. This is often the single biggest difference between two quotes.
Integrations. Payments, maps, calendars, accounting software, messaging, your existing systems. Each one is an account to configure, an interface to build against, an error case to handle, and something that can break when the provider changes it.
Device capability and offline use. Camera work, Bluetooth peripherals, background location, push notifications. Offline operation is a particularly large one: an app that keeps working without signal and reconciles its data afterwards is a meaningfully harder build than one that assumes a connection.
Quality requirements. Accessibility, security and testing aren’t features, but they are work, and they’re work you want included. How much depends on context — an app holding health or financial data carries obligations a simple catalogue doesn’t.
Administration. Somebody has to manage content, users, prices or bookings without a developer doing it by hand. An admin panel is effectively a second product, and it’s the most commonly omitted item in an underpriced quote.
That last point explains a lot of price variance on its own. Two suppliers quoting “a booking app” may differ by a large margin simply because one included a way for your staff to manage the bookings and the other didn’t.
Two illustrative briefs
These are invented examples, not client projects.
A focused internal tool. A maintenance firm wants engineers to log completed jobs, add photographs and capture a signature. Android only, because every engineer carries a company Android handset. No public sign-up — accounts are created by the office. One user role. Data syncs to the existing job system through an interface that already exists.
The scope is tight because the unknowns are few: known devices, known users, one journey, one integration, no store discovery problem to solve, no payments.
A customer-facing service app. A studio wants customers to browse classes, book, pay, manage a membership and receive reminders. Both platforms, because customers bring their own phones. Public sign-up with password resets. Card payments. Push notifications. And staff need to manage the timetable, see bookings and issue refunds — so there’s an admin interface too.
Every dimension is larger: two platforms, several roles, payment handling, personal data obligations, notifications, and a second interface for staff. None of it is exotic. It’s simply more, and more of it touches money and personal information, which raises the standard everything has to meet.
The useful observation isn’t that the second costs more. It’s that the difference is visible in the brief, before anyone quotes.
Build cost versus ongoing cost
The build is a project. Running an app is a commitment. Worth separating the two when you budget.
Things that may recur, depending on the app:
Store accounts. Apple charges an annual membership for its Developer Program, currently 99 USD per membership year, with prices varying by region and shown in local currency at enrolment. Google Play charges a one-time registration fee of US$25 for a full-distribution developer account, with no annual renewal.
Hosting and backend services. Only if your app has a backend. Costs scale with usage.
Third-party services. Payment processing, maps, messaging, error monitoring, analytics. Some are free at low volume; some are usage-priced.
Maintenance. Both platforms release major operating system versions annually, and both periodically raise the requirements an app must meet to stay listed. Libraries and certificates need keeping current. An unmaintained app degrades quietly and then breaks.
New features. Whatever you learn once real users arrive.
Not every app carries every one of these. A simple offline tool distributed to staff may have almost no running cost beyond the store account and occasional maintenance. An app with a backend, payments and notifications will have several. Ask any supplier to set out which apply to your project and roughly what drives each.
Controlling scope responsibly
The right way to reduce cost is to build less, not to build worse.
Define the problem first. One sentence, no features in it. Feature lists written before the problem is agreed tend to grow.
Find the essential journey. What must a user be able to do, start to finish, for the app to be worth having? Everything that isn’t part of that is a candidate for later.
Consider a smaller first release. Fewer screens, fewer integrations, real users sooner. Our article on MVP versus a full app covers what a first release must still include — security, error handling, testing and the rest don’t come off the list.
Defer features without deferring the foundation. If payments are coming next year, the app should be structured so they can be added, even though none of it is built now. That’s the difference between deferring work and creating a rewrite.
What we’d steer you away from is the false economy: cutting testing, skipping structure, hard-coding things that should be configurable. It reads as a saving on the first invoice and shows up as a much larger number on the second.
What to prepare before requesting a quote
- Users — who they are, and whether they’re public, customers or staff
- Platforms — Android, iOS or both, and why
- Essential features — the core journey, separated from the nice-to-haves
- Existing systems — anything the app must connect to, and whether it has a documented API
- Content — who supplies text, images and branding
- Data — what personal information the app will hold
- Administration — what needs changing without a new release
- Ownership — which accounts must be in your business’s name
- Launch goals — a date, and what’s driving it
- How you’ll measure success — bookings, hours saved, support calls avoided
Our mobile app requirements checklist goes through each of these in more detail if you’d like to work through it properly.
Send the same information to every supplier you approach. The quotes become comparable, and the differences that remain tell you something real about how each one works.
How we quote
We review your requirements and produce a written proposal for that specific project. It sets out the scope, the deliverables, the exclusions, the timing, what you own at the end, which third-party costs apply and the price.
We don’t publish a rate card, because a figure without a scope isn’t information. And if the requirements aren’t defined enough to quote from, we’ll say so and tell you what’s missing rather than quoting a number we’d have to revise later.
One thing worth stating plainly: we build new apps and complete rebuilds. We don’t take on isolated repairs to someone else’s legacy codebase — that work needs a different kind of engagement than we offer, and we’d rather say so upfront than take it on badly.
Tell us what you’re building
If you’re planning an app or a rebuild, our questionnaire covers users, features, integrations and data. It takes about twenty minutes, and you’ll end up with a clearer specification whether or not you work with us.