Why there is no single price for an app
Asking how much an app costs is a bit like asking how much a house costs. It depends on the size, the lot, the finish and what goes inside. A booking app with payments for a salon and a delivery app where customers track the courier live on a map are very different products, even if both "have a login and send notifications".
So be wary of any figure quoted before someone understands your project. What we can do is show you the pieces that make up a quote. Once you know them, you can see why one proposal is higher than another and decide what is worth building now and what can wait.
Scope: screens, flows and user roles
Scope carries the most weight. Every screen has to be designed, built, connected to the database and tested. Counting screens is not enough, though. The real work is in the flows, the full path a user takes. A simple sign-up is a short flow. A checkout with coupons, shipping, payment options and an email confirmation is a long one, with many rules and many ways to break.
User roles multiply that work. An app for end customers only is one thing. An app with customers, staff and managers, each with different screens and permissions, is another. A delivery app has at least three experiences: the buyer, the courier and the admin.
Almost every business app also needs an admin dashboard, the web area where the company manages products, schedules and prices and follows orders. It is easy to forget when you picture the app, but it is part of the product and part of the quote. A dashboard with reports, data export and team management takes more work than a basic one for editing records.
Integrations and special features
Integrating means getting the app to talk to systems you already use. Some integrations are straightforward because the service has a well-documented API. Others mean digging into a legacy system, cleaning up messy data and handling what happens when the other side goes down.
Some features also look like small items on a list but change the size of the project, because they need more architecture, more testing and sometimes paid external services. Complex business rules, such as commissions, access levels and approval workflows, fall into the same bucket. What usually weighs the most:
- Payments: cards, digital wallets, recurring subscriptions, split payouts between sellers.
- ERP and CRM: inventory, invoicing, synced catalogs, sending leads to the sales team.
- WhatsApp and third-party APIs: confirmations, reminders, shipping, social login.
- Real time: chat, courier tracking, dashboards that update on their own.
- Maps and location: routing, delivery zones, nearby search.
- Artificial intelligence: assistants, document reading, recommendations.
- Offline mode: storing data on the device and syncing when the connection returns.
Design, platforms and app store publishing
If your company already has a visual identity, with a logo, colors and typography, design starts from there and the job is applying the brand to the screens. If you are starting from nothing, the identity has to be created first, and that adds time. Clickable prototypes that let you test the experience before any code is written also belong here, and they usually save rework later.
Your choice of platforms changes the cost. Today you can serve iPhone and Android from a single codebase, and a progressive web app (PWA) can be installed straight from the browser without going through the stores. Fully native apps, with separate code for each system, take more work and make sense when the product relies heavily on device features.
Publishing on the App Store and Google Play is a separate step. It requires developer accounts, store images and copy, a privacy policy and passing each store’s review, which may ask for changes before approval.
The cost does not end at launch
Many people budget only for development and get surprised later. A live app has running costs: servers and database, domain, email and push notification services, paid APIs for maps or AI, and payment processing fees. If the app is in the stores, Apple charges a yearly developer membership and Google charges a registration fee. Many of these costs grow with your user base.
Then there is maintenance. Operating systems change, libraries get security updates and the stores update their rules. Real usage also reveals improvements and new features worth adding. Plan from day one how support and ongoing development will work once the app is live.
Why quotes vary so much between agencies
It is common to get very different proposals for the same project. Most of the time they are not quoting the same thing. One includes an admin dashboard, testing on real devices and store publishing. Another delivers only the app, with no dashboard, and leaves the rest as "extras" that show up halfway through.
How the app is built and who builds it also matter. Reskinning a template costs less than custom development but limits what you can change later. Clean, documented code costs more up front and far less when the app needs to grow or move to another team. Do not compare the final numbers. Compare what is written in each proposal.
How to cut costs without cutting quality
The safest way to spend less is to build fewer things, not to build them worse. Skipping tests or settling for a fragile codebase gets expensive the moment the app needs fixes or a new feature. Cutting scope carefully keeps what matters.
Starting with an MVP, the smallest version that already solves the core problem, is the most common path. We cover how to scope that first version in our post on what an MVP is. A few practices that help:
- Write down in one sentence the problem the app solves and drop anything that does not serve it.
- Separate what you need at launch from what would be nice later.
- Split the project into milestones, each with a working deliverable.
- Start with a PWA and leave store publishing for when usage justifies it.
- Use ready-made services for parts that are not your differentiator, such as login and email delivery.
What a serious proposal should spell out
A good proposal leaves little room for surprises. Before you sign, check that it covers:
- Detailed scope: screens, flows, user roles, dashboard and integrations.
- Total timeline, broken down by milestone.
- A fixed price, with payments tied to deliverables.
- What you receive at the end of each milestone and how you will test it.
- What is not included, such as hosting, store accounts and third-party services.
- How support and scope changes work once the project starts.
How BG Coding puts a quote together
We do not work from a price list. First we get to know your business, your audience and the problem the app needs to solve, in an assessment call. Then we send a proposal with scope, milestones, timeline and a fixed price, including what is out of scope. If the budget is tight, we suggest an MVP or a first phase that already solves the core problem.
If you have an app idea and want to know what it takes, tell us about it on our quote page and we will get back to you with an assessment.