What drives the cost of building an app or MVP?

Key points

• Scope sets most of the cost: count the user roles and the journeys each one needs.
• Every extra platform, integration and admin screen is work to build, test and keep working.
• AI features carry a running cost per use, plus the work of checking that the answers are good.
• Cutting testing and review lowers the first bill and raises every bill after it.
• Plan for life after launch: hosting, updates, app store accounts and fixes.
• A useful estimate comes after scoping, in writing, and is compared like with like.

Why this page has no numbers

Ask ten teams what an app costs and you will hear ten answers, because “an app” can mean a single form or a marketplace with payments, chat and three kinds of users. A figure quoted before anyone has seen your scope is either padded to cover the unknowns or low and certain to grow. So this guide does not give one. It explains what moves the cost, so you can shape the scope before you ask for a price and judge the estimates you get.

The same drivers apply to an MVP, a full web or mobile app, and an AI agent. What a first version should include is covered in How to build an MVP.

Scope: user roles and flows

The biggest driver is how much the product has to do. Two measures make that concrete. A user role is a kind of person who uses the product differently: a customer, a provider, an admin. A flow is a journey one role takes from start to finish: sign up, book, cancel, get a refund. Each role brings its own screens, permissions and edge cases, and each flow has to be designed, built and tested, including what happens when it goes wrong.

• A one-sided product, with one kind of user doing one main job, is the smallest shape.
• A two-sided product, such as a marketplace, adds a second set of roles and the flows between them: matching, messaging, reviews and disputes.
• Permissions add work: who can see, edit or approve what. See What is RBAC?.
• Edge cases are where scope hides: failed payments, partial refunds, expired invitations, deleted accounts.

The cheapest feature is the one you do not build yet. How to prioritize features has methods for cutting the list down to the core path.

Platforms and design depth

A web app is one codebase for every device with a browser. Native iOS and Android apps are two separate builds. Cross-platform frameworks let one codebase serve both phones, which usually costs less than two native apps, though some features still need platform-specific work. Every mobile release also goes through store review and has to be tested on real devices.

Where to start is covered in Web app vs mobile app, iOS or Android first? and React Native vs Flutter.

Design depth is the second lever. A product built from a well-made component library with familiar layouts needs far less design time than one with custom illustration, motion and a new visual language. Accessibility belongs in the scope from the start: the W3C’s WCAG guidelines explain how to make web content usable by people with disabilities, and building to them early is easier than retrofitting them. What is WCAG? explains the levels.

Integrations, data and admin tools

• Each third-party service, such as payments, maps, email, calendars or a CRM, is a connection to build, test and keep working when the other side changes. Many also charge their own fees as you grow.
• Connecting to an older internal system is usually harder than connecting to a modern service, because the documentation is thin and the data is messy.
• Moving data from spreadsheets or an old product needs mapping, cleaning and a rehearsal before the real move.
• Admin tools are easy to forget. Someone has to manage users, fix records, issue refunds and read reports, and each of those is a screen to build.
• Reports and dashboards look small and often are not, because they depend on the data being clean and complete.

How services talk to each other is explained in API vs webhook, and what to check before taking real money is in Before you switch to live payments.

Security, compliance and AI features

Every product needs the basics: secure sign-in, encrypted connections, backups and sensible permissions. Cost rises when the data is sensitive or regulated, such as health records, financial data, children’s data, or personal data covered by privacy laws where your users live. That can bring audit logs, choices about where data is stored, stricter access controls, and reviews or certifications that take real effort.

AI features change the shape of the cost. Model providers bill for usage, typically per token of input and of output, so the bill grows with every user, every request and the length of each prompt and answer. On top of the running cost, an AI feature needs evaluation: a set of test cases that checks the answers stay good as prompts and models change. Where a wrong answer matters, it also needs a person reviewing the output before it is used.

Both sides are covered in How to evaluate AI agents and LLM features and How to reduce LLM costs.

Quality, the team, and the cost after launch

Testing and code review take time up front. Skipping them makes the first version cheaper and every later change slower and riskier. Martin Fowler argues that the main job of internal quality is to lower the cost of future change, which is why a team that cuts quality to hit a number is usually moving cost, not removing it. What is technical debt? explains how it builds up.

Who does the work matters as much as what the work is. Senior people cost more for the same time and usually need less of it. Someone has to run the project and make decisions; if the team does not, you will. How the work is managed also changes the bill: small steps you can see let you stop or change course early, while one large hand-off at the end hides problems until they are expensive. Fractional CTO vs agency vs freelancer compares the options.

Launch is not the end of the spending. Plan for:

• Hosting, databases, storage and monitoring, which grow with usage.
• Third-party services and model usage, billed as you use them.
• App store accounts: publishing on Apple’s App Store needs a paid annual developer membership, and Google Play charges a one-time registration fee.
• Maintenance: security patches, updates to libraries and operating systems, and fixes for what users find.
• New features, once real users show you what they need.

How to get a useful estimate

A useful estimate is the result of scoping, not a guess at the start. The GOV.UK service manual makes the same point for public services: understand the problem before you commit to building, and do not start building during discovery.

1. Write down who the users are, the one job the first version must do, and how you will know it worked. How to write a PRD has a template.
2. List the roles, the flows for each, the platforms and the integrations. Mark what is essential and what can wait.
3. Ask for a short scoping exercise before a full estimate, and keep what it produces: the feature list, the flows and the open questions.
4. Get the estimate in writing, broken down by feature or phase, with the assumptions and exclusions stated.
5. Ask how changes to the scope are handled and priced, before work starts.
6. Ask for the running costs after launch as well as the cost of the build.

When you compare estimates, compare like with like. Check that each covers the same features, platforms, design depth, testing, admin tools and launch work, and says who owns the code. A lower number that leaves out testing or the admin screens is not cheaper; it is a different product. How to choose a software development company has the questions to ask.

BYD Tech prices by the project or the week, never by the hour, with a ballpark on the intro call and a written estimate after scoping. MVP development describes how a first version starts.