Menu

Cost and timeline

What Drives Cost and Timeline

The short answer

A custom app's cost and timeline are driven mostly by scope (how many kinds of users, screens, rules and integrations), risk (sensitive data, payments, regulation), platforms (web, iOS, Android), the team (model, location, seniority) and how fast decisions get made on your side.

This guide doesn't quote prices: rates differ too much by country, team and year for any figure to be honest. Instead, it shows how to get real numbers you can compare: one clear brief, sent to several teams, priced in the same shape.

Updated November 11, 2026 · 15 sources cited

The factors that move scope and budget

FactorWhy it moves costHow to keep it in check
Kinds of usersEach role (customer, staff, admin, partner) adds screens, permissions and testing.Launch with the fewest roles that prove the idea.
Business rulesExceptions, approvals and edge cases multiply the work.Write down the rules you actually follow, and drop the rare ones from version one.
IntegrationsEvery connection to another system (payments, CRM, accounting) has its own API, limits and failure modes.List each one, and ask which can wait or be done by hand at first.
PlatformsA web app, an iOS app and an Android app can mean three things to build, test and publish [1].Start with the platform your users actually use.
Sensitive dataHealth, payment or children's data brings legal duties and security work [2] [3] [4].Collect only what you need; use established providers for payments and sign-in.
AccessibilityMeeting WCAG takes design and testing effort, and is far cheaper planned than retrofitted [5].Put the target level in the brief from day one.
Existing dataMigrating messy spreadsheets or an old system takes cleanup and checking.Clean the data before the build starts, or price migration separately.
Team model and locationRates vary widely by model, seniority and country.Compare like with like: the same brief, the same pricing shape.

What moves the timeline

  • Uncertainty at the start. Estimates made before discovery have the widest range; they narrow as decisions are made, which is known as the cone of uncertainty [6]. A single date before discovery is a guess.
  • Optimism. People reliably underestimate how long tasks will take, even with experience of overruns [7].
  • Waiting on the client. Unanswered questions, late content and slow sign-offs stall teams that are otherwise ready.
  • Scope added mid-build. Every addition displaces something or extends the date.
  • Third parties. App store review [1], developer account setup [8] and integration partners all run on their own schedules.
  • Adding people late. It tends to slow things down before it speeds them up [9].

Pricing models and what they mean for you

ModelHow it worksGood whenWatch for
Fixed priceOne price for a defined scope [10].Scope is small and well understood.Changes cost extra; risk may be priced in.
Time and materialsYou pay for time actually spent [11].Scope will evolve as you learn.Needs regular review of progress against budget.
PhasedDiscovery priced first, then a build estimate based on what it found.Most new products.Make sure discovery produces something you own and can take elsewhere.
Retainer or support planA regular fee for maintenance and improvements [12].After launch.Know exactly what's covered and the response times.

How to write a brief that gets comparable proposals

A brief is a few pages that tell every team the same thing. It doesn't need technical language. It needs to be specific about the problem and honest about what you don't know.

What to put in your brief

  • About you: who you are, what you do, and who'll be the decision-maker on the project.
  • The problem: what's going wrong or missing today, in your own words, with an example.
  • The users: each kind of user and the main things they need to do.
  • What exists: current tools, spreadsheets and data, and anything the app must connect to.
  • Must-haves for version one, and a separate list of later ideas.
  • Platforms: web, iOS, Android, and why.
  • Constraints: dates that matter and why, data rules [2] [3], accessibility target [5].
  • Budget range, if you can share it. It lets teams propose what fits, not guess.
  • What you want back: discovery priced separately, a build range, support terms, the team, and two references.

Ask every team to answer in the same shape

  • Price and length of discovery, and what you get at the end of it.
  • A range for the build, with the assumptions behind it.
  • Pricing model, and how changes are handled.
  • Support after launch: what's included, response times and cost [12].
  • Who'll do the work, and code and account ownership terms [13].

With answers in the same shape, you can lay proposals side by side and see the real differences. How to choose a development partner covers what to ask next.

Where to check real prices

  • Proposals from your brief: the only numbers that fit your project. Three is a reasonable minimum to compare.
  • Peers: organizations like yours that commissioned something similar recently. Ask what they paid and what they'd change.
  • Published rate cards: some freelancers and studios publish rates; read what's included.
  • Platform pricing pages: for hosting, no-code tools and app store fees, read the vendor's own page on the day you decide [14] [15].

Worked example

Worked example

Cutting scope to hit a deadline

The situation
An illustrative scenario: a nonprofit needs a volunteer sign-up app before a seasonal campaign. The first proposals cover a web app, two mobile apps, a donor portal and a CRM integration, and none fits the date.
The decision
They fix the date and flex the scope: a mobile-friendly web app for volunteer sign-up only, with a weekly CSV export to the CRM. The donor portal and native apps move to the "later" list.
What to take from it
The fastest way to cut cost and time is to cut what's in version one, not to squeeze the team.

Questions people ask

How much does it cost to develop a custom app?

It depends on scope, risk, platforms and team, so a single figure would mislead. Write one brief, send it to at least three teams, and ask them to price discovery separately from the build.

Why do estimates change after discovery?

Because discovery replaces guesses with decisions. Estimates naturally narrow as uncertainty is removed [6].

Is fixed price safer than time and materials?

Only when scope is small and well understood. Otherwise, risk gets priced in or changes get expensive [10]; time and materials with regular review is often fairer for evolving products [11].

How do I make an app cheaper to build?

Fewer kinds of users, fewer integrations, one platform first, established services for payments and sign-in, clean data, and fast decisions on your side.

How to Choose a Development PartnerFreelancers, agencies, product studios and in-house hires compared, with questions to ask, red flags and what ongoing support should include.The Custom App Development Process, Stage by StageDiscovery, design, build, launch and maintenance, with what the client must decide and deliver at each stage.Custom App, No-Code or Off-the-Shelf: How to DecideA decision framework for custom builds, no-code tools, AI-generated MVPs and existing software, and when each stops working.

Sources

Every numbered claim on this page links here. Each source is public; follow the link to check it.

  1. App Review Guidelines, Apple Developer
  2. Regulation (EU) 2016/679 (General Data Protection Regulation), EUR-Lex
  3. HIPAA for Professionals, U.S. Department of Health and Human Services
  4. OWASP Top Ten, OWASP Foundation
  5. Web Content Accessibility Guidelines (WCAG) 2.2, W3C
  6. Cone of Uncertainty, Wikipedia
  7. Planning fallacy, Wikipedia
  8. D-U-N-S Number (enrolling as an organization), Apple Developer
  9. Brooks's law, Wikipedia
  10. Fixed-price contract, Wikipedia
  11. Time and materials, Wikipedia
  12. Service-level agreement, Wikipedia
  13. Airtable plans and limits, Airtable
  14. Google Play Console, Google