How to Estimate App Development Cost Yourself Before You Get a Quote

You cannot produce an accurate estimate for your own app, and you can produce one accurate enough to tell whether a quote is plausible. That is a genuinely useful capability, because the most expensive mistake in app procurement is choosing the cheapest bid without noticing it quoted a smaller product than the others.

The method below takes about two hours, uses no special knowledge, and produces a range you can hold quotes against. Online cost calculators do not do this, because they ask for app type and screen count, neither of which drives cost.

Step one: list the features as user actions

Write down what a user can do, in plain sentences, one per line. Not screens. Actions.

A user can create an account. A user can invite a colleague. A user can create a job. A user can attach photos to a job. A user can see all jobs assigned to them. An administrator can see all jobs across the company. A user can pay for a subscription.

Aim for twenty to forty lines for a first version. If you are over sixty, you are not describing a first version, and that fact alone is worth knowing before you receive quotes.

Step two: assign each action a size

Three buckets, and be honest rather than optimistic.

Small, roughly 8 to 20 hours. A screen displaying data you already have. A simple form writing to one table. A settings toggle. A static content page.

Medium, roughly 20 to 60 hours. Anything involving a list with filtering and search. A multi-step form. File or photo upload. A notification. A report. Anything that touches two or three tables.

Large, roughly 60 to 200 hours. Payments. Authentication with organisations and roles. Any integration with an external system. Offline behaviour. Real-time updates. Search across a substantial dataset. Anything with compliance requirements attached.

Two rules that keep this honest. Anything involving money or an external system is large, always, even when it sounds simple. And permissions are large as soon as there is more than one type of user, because the check has to exist in every query rather than in one place.

Step three: add the invisible work

This is the step that makes the estimate resemble a real quote, and it is the step every online calculator omits.

Sum your feature hours, then apply each of these. The multipliers compound, which is why a feature list that feels like 400 hours becomes a project closer to 750.

Step four: convert hours to money

Multiply by a blended rate. Use $100 to $150 for a US-led team, $60 to $100 for nearshore or a hybrid structure with distributed engineering, and $35 to $70 for offshore. Blended means the average across designers, engineers, quality assurance, and project management rather than a senior engineer's rate.

Then produce a range rather than a number: your calculation minus 20 percent as the optimistic end, plus 30 percent as the realistic end. Real estimates have ranges, and a single confident figure from anyone is a sales position rather than an estimate.

A worked example

A field service app: technicians record jobs offline with photos, dispatchers assign work from a web dashboard, and completed jobs sync to an accounting system.

Feature actions: 28 lines. Sized as 9 small, 12 medium, 7 large. Using midpoints, that is roughly 9 times 14, plus 12 times 40, plus 7 times 120, which comes to about 1,446 hours of feature work. Note that offline behaviour and the accounting integration are two of the seven large items and account for a substantial share on their own.

Add the invisible work at midpoints: admin interface 18 percent, design 25 percent, quality assurance 22 percent, project management 12 percent. That is roughly 1,446 plus 1,113, so about 2,559 hours, plus 30 for release and 60 for discovery. Call it 2,650.

At a blended $85 per hour for a hybrid team, that is roughly $225,000, with a range of about $180,000 to $290,000.

That number is not a quote. What it is good for is recognising that a $60,000 bid on this brief has quoted something else, and identifying which of the seven large items it left out.

The purpose of this exercise is not to price your app. It is to know which questions to ask. If your own estimate is $220,000 and a bid comes in at $70,000, the useful move is to ask that bidder how they handled offline sync and the accounting integration, and the answer will tell you whether they are efficient or optimistic.

Sizing reference for common features

Founders consistently mis-size the same items, so here is a reference. These are rough professional-team figures including both client and server work, and they assume a competent team rather than a heroic one.

Two observations from that table. Authentication with organisations and roles costs more than most founders' entire mental model of the backend, and it is unavoidable in any product sold to a company. And an undocumented integration can exceed a whole feature area, which is why it belongs in the first engineering sprint rather than the last.

Adjusting the estimate for your situation

Four multipliers to apply after the base calculation, because they affect everything rather than individual features.

Two user types: multiply feature hours by 1.7 to 2.0. Each audience needs its own flows, permissions, and interface. This is the largest single multiplier and the most commonly ignored.

Regulated data: add 30 to 60 percent. Audit logging, access control, encryption handling, retention, and the documentation to support a security review. Largely sequential work that cannot be parallelised.

Both mobile platforms natively: add 60 to 80 percent to client hours. Cross-platform instead adds roughly 10 to 15 percent over a single platform, which is the arithmetic behind the standard recommendation.

Replacing an existing system: add 10 to 20 percent. Data migration and a parallel-running period are their own project and are absent from almost every client's feature list.

Apply these before comparing against quotes, because a bid that looks low may simply be the only one that noticed you have two user types.

How to use the estimate against real quotes

Send an identical one-page brief to three or four firms, then compare against your own figure.

A bid near your range with a detailed exclusions list is probably real. A bid far below with no exclusions section has almost certainly assumed away something you need, and the exclusions section is where you would have found out. A bid far above may include work you did not account for, which is worth asking about rather than dismissing, since compliance, migration, and enterprise requirements are commonly missing from a client's own list.

Then ask every bidder the same three questions and compare the answers rather than the numbers. What is explicitly out of scope. What worries you most about this project. And what happens if the estimate turns out to be wrong.

That last question is the one that reveals the model. Under fixed-scope pricing the agency absorbs estimation error on the agreed scope; under hourly billing you do. Bolder Apps prices project work fixed-scope rather than hourly and turns proposals around in one to two business days against an industry norm closer to one to two weeks, and both details are worth using as benchmarks across your shortlist rather than as claims about one firm.

What your estimate will systematically get wrong

Four blind spots, so you can allow for them.

You will underestimate integration work, always. Someone who has connected to your specific target system knows things you cannot know from the outside, including whether the API supports writing and whether access is a credential or an approval process.

You will underestimate permissions, because you are thinking about what users see rather than about the check that must exist in every query behind it.

You will forget migration if you are replacing something. Data migration and a parallel-running period are their own project and routinely 10 to 20 percent of a replacement build.

You will omit compliance if you are not sure whether it applies. HIPAA, PCI DSS, or SOC 2 scope adds 30 to 60 percent, and whether it applies is a question for counsel rather than for a spreadsheet.

When to stop estimating and buy discovery

If your own range is wider than roughly two to one, or if two or more of your large items are integrations you cannot assess, the honest answer is that no useful estimate exists yet and a paid discovery engagement is the correct next purchase.

Discovery costs $3,000 to $15,000, produces a specification and integration plan you own, and can be taken to multiple bidders so that everyone quotes the same defined scope. Bolder Apps sells paid discovery as a standalone engagement, and buying it separately has a second benefit beyond the document: it lets you evaluate how a firm thinks for a few thousand dollars rather than on the strength of a sales call.

Sources

• US Bureau of Labor Statistics, Occupational Outlook Handbook, software developers
• Apple Developer Program and App Store Review Guidelines, developer.apple.com
• Google Play Console registration and policy documentation, support.google.com/googleplay/android-developer
• PCI Security Standards Council, PCI DSS scope guidance, pcisecuritystandards.org
• US Department of Health and Human Services, HIPAA Security Rule guidance, hhs.gov
• Project Management Institute, PMBOK Guide, on estimation techniques