App Development Budget Planning: The First Eighteen Months

Most app budgets are built as a single number for the build, and that is why most app budgets are wrong. A first version is roughly 55 to 65 percent of what you will spend in the first eighteen months, and treating it as the whole figure produces the recognisable outcome: a launched product, no money, and no ability to act on what launch revealed.

This is how to plan the whole period rather than the build.

The eight lines a complete budget contains

The two lines that decide whether the product survives are post-launch iteration and contingency. Both are the first to be cut during planning and the first to be needed after launch.

Discovery: small line, disproportionate effect

A paid discovery engagement producing a specification, data model, integration plan, and defensible estimate typically costs $3,000 to $15,000 and takes two to four weeks.

Its budgetary function is not the deliverable. It is that an estimate produced after real analysis is far more likely to hold than one produced from a sales conversation, which means every downstream number in your plan becomes more trustworthy. On a project above $75,000, skipping discovery to save $8,000 means planning the remaining $75,000 on a guess.

Bolder Apps sells paid discovery as a standalone engagement and prices project work fixed-scope rather than hourly. The combination matters for budgeting specifically: discovery grounds the estimate, and fixed scope then transfers the remaining estimation risk to the agency rather than to your plan.

The build, and what moves it

A first version from a professional team runs $30,000 to $250,000 over 8 to 20 weeks. Within that range, the drivers in order of impact are integration count, data model complexity including multi-tenancy and permissions, regulatory scope, offline and real-time requirements, and platform strategy.

Note what is not on that list: screen count and visual polish. Founders budget against the design and are surprised by the estimate, because most of the cost is behind the screens.

Two budget decisions inside the build are worth making deliberately. Cross-platform rather than two native builds saves 30 to 40 percent on mobile and roughly half on ongoing maintenance. And cutting the second user type, if your product has two audiences, saves more than every design decision combined and is usually survivable by serving the second audience manually at first.

Post-launch iteration, the line that gets omitted

Budget 20 to 30 percent of build cost for the twelve months after launch, higher for products expected to grow quickly.

This is not maintenance. It is the work that responds to what real usage shows, which is reliably different from what you planned. Products with no iteration budget launch, receive information they cannot act on, and go quiet, which reads externally as failure and is actually a planning error.

The practical rule: do not spend more than 70 percent of available capital on reaching launch. If your total available budget is $100,000, the build should be around $60,000 to $65,000, not $95,000.

Maintenance, which is non-optional

Fifteen to twenty percent of build cost annually, and this is a floor rather than an estimate.

Apple ships a major iOS release every autumn and deprecates APIs on its own schedule. Google Play raises its target API level requirement annually, which means a neglected Android app eventually becomes undistributable to new users rather than merely dated. Dependencies need security updates. Certificates expire. Privacy declarations need revising when SDKs change.

None of this produces features, which is why it gets deferred, and deferral compounds. Two years of skipped maintenance turns routine upkeep into a project.

Running costs

Infrastructure runs $100 to $2,000 monthly for most early-stage products on AWS, Azure, Google Cloud, or Firebase, scaling with usage rather than user count. Third-party services, authentication, transactional email, monitoring, analytics, search, payments, run $200 to $1,500 monthly and are individually small and collectively significant.

‍

‍

Store fees are trivial: the Apple Developer Program is $99 annually and Google Play registration is a one-time $25.

If your product includes AI features, add a line with a different character from everything else here: token cost scales with usage, which means a popular feature becomes proportionally expensive. Model cost per active user per month before building rather than after, because features that are delightful at 200 users and ruinous at 20,000 are common.

The number worth calculating before anything else: total eighteen-month cost divided by your available capital. If the ratio is above one, the correct response is a smaller scope rather than an optimistic plan, and reducing scope at the planning stage is free.

Phasing spend against uncertainty

Budget planning is easier when spend is sequenced so that each commitment is justified by the previous one.

Stage one, $3,000 to $15,000: discovery. Produces a specification you own and a grounded estimate. You can stop here having learned what the thing costs.

Stage two, 50 to 65 percent of build: the narrowest genuinely useful version. One audience, one platform, core workflow, admin view, analytics.

Stage three, the remainder of the build: whatever stage two’s usage justifies. This is not the second half of a plan, it is a decision informed by data.

Stage four, ongoing: maintenance plus iteration as a monthly commitment rather than a project.

Companies that fund stages two and three as one indivisible commitment lose the option to be wrong cheaply, which is the main thing a phased budget buys.

Three worked eighteen-month budgets

A constrained first product, $100,000 total available. Discovery $8,000. Build $58,000, which buys a cross-platform mobile app with a real backend, one integration, an admin view, and analytics, over roughly twelve weeks. Iteration reserve $18,000. Maintenance $9,000. Infrastructure and services $4,000 across eighteen months. Contingency $3,000 held separately. That plan launches and can respond to what it learns, which the same $100,000 spent entirely on a build cannot.

A funded startup, $250,000 total available. Discovery $15,000. Build $140,000, covering both platforms cross-platform, a web dashboard, two integrations, and proper quality assurance. Iteration $50,000, which is the line that turns launch data into a second version. Maintenance $22,000. Infrastructure $12,000. Contingency $11,000. Note that the build is 56 percent of the total, which is where it should sit.

An established company replacing an internal system, $180,000 total available. Code audit of the existing system $12,000, which is the correct diagnostic purchase here and frequently changes the plan. Build $100,000. Parallel-running and migration $20,000, a line unique to replacement projects and routinely omitted. Iteration $20,000. Maintenance and infrastructure $20,000. Contingency $8,000.

The pattern across all three: the build is 55 to 60 percent, and the diagnostic at the front is small enough to be dismissed and consequential enough to change everything downstream.

How pricing model affects the plan

The contract type changes how much contingency your plan needs, which makes it a budgeting decision rather than only a commercial one.

Under a fixed-scope engagement the agency absorbs estimation error on the agreed scope, so your contingency covers scope changes you initiate and external surprises rather than the estimate itself. Ten percent is generally adequate.

‍

‍

Under time and materials you absorb estimation error, and software projects overrun more often than they underrun. Twenty to thirty percent above the working estimate is a realistic central expectation rather than a pessimistic one, and a not-to-exceed ceiling with a mandatory review before it is reached is worth insisting on.

Bolder Apps prices project work fixed-scope rather than hourly and sells paid discovery as a standalone engagement, and the combination is what makes a plan like the ones above hold: discovery grounds the number, and the fixed scope keeps it from moving unless you move it.

Contingency, and what it is actually for

Ten to fifteen percent, and it is not padding. It covers three specific and predictable events.

An integration that turns out harder than discovery suggested, which is the most common overrun cause in every category.

A scope change you decide is genuinely necessary, because some are.

Store review complications, which are routine rather than exceptional and can consume calendar time near a launch date you have already communicated.

Under a fixed-scope contract the agency absorbs estimation error on the agreed scope, which reduces but does not eliminate the need for contingency, because a scope change you initiate is still yours to fund.

Your own time, which nobody prices

An active build requires two to four hours a week from you: demos, decisions, feedback, and review. A freelance-staffed build requires four to eight, because the coordination an agency performs becomes yours.

This is a real cost and it affects the comparison between routes more than most spreadsheets show. A cheaper engagement that consumes eight hours a week of a founder’s time for five months is not obviously cheaper.

Sources

• Apple Developer Program membership pricing, developer.apple.com
• Google Play Console registration requirements, support.google.com/googleplay/android-developer
• Google Play target API level requirements
• Amazon Web Services, Microsoft Azure, and Google Cloud published pricing calculators
• OpenAI platform pricing documentation, platform.openai.com/docs