How I Estimate a Mobile App Project (And Why You Get a Range)

“How much will my app cost?” is the first question almost every founder asks me. It’s a fair question. The honest answer is usually another question: “Which app?”

Two ideas that sound the same in a single sentence (“a marketplace app with payments”) can differ by several times in effort once you look at the details. One has a single user type and card payments. The other has three roles, payouts to sellers, refunds, an admin panel and offline support.

I’ve been building mobile apps since founding Crazybot Studio in 2018 and freelancing on Upwork since 2021. This post explains how I turn an idea into an estimate, and why the estimate you get from me is a range, not a single number.

Step 1: Break the app into features users can see

I start by writing down what a user can actually do, screen by screen, in plain language:

• Sign up with email or Apple/Google.
• Browse a list of items, filter by category.
• Book an item and pay by card.
• Get a push notification when the booking is confirmed.
• See booking history.

Each line becomes a small chunk of work I can size on its own. Sizing “a booking app” is guessing. Sizing “a filterable list backed by an API” is something I’ve done many times.

I also write down who uses the app. Every additional role (customer, provider, admin, support) multiplies screens, permissions and test cases. “Users can also be sellers” is one sentence in a brief and a lot of work in practice.

Step 2: List the integrations separately

Integrations are where estimates go wrong most often, because each one brings rules you don’t control. I list them on their own:

• Payments. One-off card payments, subscriptions, or marketplace payouts are very different jobs. In-app purchases come with App Store and Google Play rules. Marketplace payouts with something like Stripe Connect involve onboarding sellers and handling disputes. (I wrote about Stripe Connect in Flutter if you want the details.)
• Maps and location. Showing a pin is small. Live tracking, geofencing or route drawing is not.
• Authentication. Email and social login is routine. Roles, invitations, multi-factor auth or company accounts add up.
• Admin panel. Almost every app needs one, and it’s often missing from the first brief. Someone has to manage users, content and refunds.
• Backend. Is there an existing API, or are we building one? Firebase can carry a lot of apps; others need a custom backend (I often use .NET for that).

Each integration gets its own line and its own risk note.

Step 3: Separate the knowns from the unknowns

Some features I can size with confidence because I’ve built them many times. Others carry real unknowns: a third-party API with thin documentation, a hardware integration, a legacy backend nobody has touched in years.

I mark each item as known, somewhat known or unknown. The unknowns are what make the range wide. They’re also what a discovery phase is for.

Discovery: paying a little to learn a lot

For anything beyond a small app, I suggest a short discovery phase before committing to a full estimate. In discovery I:

• Walk through the flows with you and agree on what’s in version one and what can wait.
• Check the risky integrations: read their docs, test their sandbox, confirm they do what we need.
• Look at any existing code, backend or designs.
• Produce a written scope, a feature list with sizes, and a milestone plan.

Discovery is a small piece of work compared with the build, and it’s the cheapest place to find out that a key API doesn’t support what you need. You keep the scope document either way, so you can take it to another developer if you want.

Why you get a range

A single number looks precise, but it hides the uncertainty instead of removing it. I give a low and high for each feature, and for the total.

The low end assumes things go as expected. The high end covers the realistic surprises: an API that behaves differently than documented, a store review that asks for changes, a design that needs another round. A narrow range means we understand the work well. A wide range is a signal that something needs more discovery, not a sign that I’m padding.

As an illustration (not real pricing), a feature list might look like this:

Feature	Size	Confidence
Email + social sign-in	Small	High
Item list with filters	Small to medium	High
Card payments with receipts	Medium	Medium
Live location tracking	Medium to large	Medium
Admin panel	Medium to large	Low until scoped

Ranges also make trade-offs visible. If the total is higher than your budget, we can look at the table together and decide what moves to a later phase.

What inflates cost

These are the things that tend to push an estimate toward the high end, roughly in order of how often I see them surprise people:

• Fully custom design. Custom animations, illustrations and non-standard controls take longer than a clean design built on platform components. Both are valid; they’re just priced differently.
• Offline support. Making an app work without a connection means local storage, syncing and conflict handling. It’s worth it for some apps and overkill for others. (More on that in offline-first Flutter apps.)
• Real-time features. Chat, live updates and presence need a different backend approach and a lot more edge-case testing.
• Multiple roles. As above, every role adds screens, rules and tests.
• Store compliance. Subscriptions, account deletion, privacy disclosures, health or kids’ content rules. Apple and Google both have requirements that need to be built, not just ticked.
• “Just like app X.” Big apps look simple because thousands of people worked on the details.

Milestones and change requests

I split the project into milestones that each end in something you can install and try: for example, sign-in and the main list first, then payments, then notifications and polish. You see progress regularly, and problems surface early instead of in the last week.

Change is normal. Once founders hold a working app, they always have new ideas, and many of them are good. I handle changes in a simple way:

• New idea comes in. I write it down and size it.
• We decide together: add it now (and adjust the timeline or budget), swap it for something of similar size, or park it for the next phase.
• Nothing gets silently absorbed. That protects your budget and keeps the estimate honest.

One client described it well:

“Tanjim made reasonable accommodations and discussed any budget concerns ahead of time so that there were not any unexpected costs.” — Jeremy Gill

That’s the goal: no surprises.

Don’t forget life after launch

Launch isn’t the end of the budget. Every app needs ongoing work:

• OS and store updates. New iOS and Android versions, new target SDK requirements and new store policies arrive every year.
• Dependency updates. Flutter and its packages move fast. Staying current is much cheaper than catching up after two years.
• Bug fixes and monitoring. Real users find things testers don’t.
• Backend and service costs. Hosting, databases, push, maps and email services all have bills.

I include a maintenance note with every estimate so you can plan for it from day one.

Takeaways

• Good estimates start from what users can do, broken into small features.
• Integrations and extra user roles are where most cost hides. List them separately.
• A short discovery phase is the cheapest way to shrink the unknowns.
• Expect a range; a wide one means “we need to learn more”, not “padding”.
• Agree on how change requests work before the project starts.
• Budget for maintenance after launch.

If you have an app idea and want an honest, itemized estimate, get in touch and we’ll start with what your users need to do.