How do app developers charge for projects?

App development quotes can look confusing, even contradictory. Two agencies quote the same project brief and come back with figures that differ by a factor of three. One charges a flat fee, another bills by the hour, a third asks for a monthly retainer before any work begins. Without understanding what sits behind each number, it is genuinely difficult to know what you are buying, or whether the cheapest option is a bargain or a warning.

The pricing model shapes where risk sits and determines what gets built and what gets cut.

The pricing model an agency uses shapes the project as much as the design brief does. It determines where risk sits, who controls scope, and what happens when the brief changes. And briefs always change. Understanding how developers charge is a design question, because how money flows through a project affects what gets built and what gets cut.

We work on consumer apps, social products, marketplaces, and sports platforms, and we see the same misunderstandings surface across all of them. Clients arrive with a budget in hand, a quote from a cheaper agency, and a request to skip the parts of our process that make the work cost what it costs. This article is our attempt to explain what the different pricing models actually mean, what each one protects, and what each one leaves exposed.

Fixed-price contracts

A fixed-price contract sets a single agreed figure for a defined piece of work. The client knows from day one what they will pay, and the agency commits to delivering a specified scope within that budget. The appeal is obvious: no surprises, no negotiation mid-project, no invoices that climb as the work gets harder.

The catch is that fixed pricing only works when scope is genuinely fixed. Every fixed-price project contains an implicit deal: the agency assumes the risk of uncertainty in exchange for a price that includes a buffer to cover it. The more vague the original brief, the larger that buffer needs to be, which means fixed-price contracts on loosely defined projects tend to be priced conservatively, sometimes very conservatively.

What gets fixed and what does not

In practice, what is fixed is the price. The timeline can flex. The feature set can be reinterpreted. Agencies working to a fixed price have a rational incentive to resolve ambiguity in the direction that costs them least, so a feature described loosely in the brief may arrive stripped back. This is arithmetic.

Fixed-price contracts suit projects with clear, stable requirements: a booking flow built to a defined spec, a dashboard with known inputs and outputs. They suit clients who cannot tolerate financial uncertainty. They suit smaller, well-defined builds. For anything exploratory, complex, or genuinely new, the model introduces pressure that usually shows up in the quality of what gets delivered.

Time-and-materials billing

Time-and-materials billing charges for the hours worked and the resources used, at an agreed rate. The client pays for actual effort rather than a projected effort wrapped in contingency. There is no fixed end figure, though most agencies will provide an estimate with a range, and some will agree a cap beyond which they absorb costs.

This model shifts financial risk from agency to client. If the project is simple and the estimate was accurate, the client pays roughly what they expected. If requirements expand, complexity emerges, or stakeholders request changes, the cost climbs accordingly. Transparency is the trade-off: a time-and-materials invoice shows exactly what was done and when, which makes the billing legible even when the total is higher than hoped.

Where this model performs well

Time-and-materials works well on projects where requirements are likely to evolve, where iterative development and user testing will shape the build, or where the client wants genuine visibility into how the budget is being spent. It rewards good project management on both sides and punishes poor communication. An engaged client who reviews progress weekly and makes decisions quickly will almost always spend less under this model than one who waits for a big reveal and then requests substantial changes.

Development is typically the largest cost driver in any app build, often accounting for 50 to 70 percent of total spend, according to Create Anything, 2025. Under time-and-materials billing, that figure is directly visible, which can sharpen decisions about what to build first.

Retainer and ongoing support agreements

A retainer secures a set amount of an agency's time each month, typically at a slightly reduced rate, in exchange for commitment. The client gets predictable access to the team. The agency gets predictable revenue. Both sides benefit from continuity, because a team that already understands the codebase, the brand, and the user behaviour is faster and more reliable than one starting fresh each time.

Retainers suit products that are live and need ongoing development, user research, design iteration, or technical maintenance. They are poorly suited to pre-launch builds where the scope is still taking shape and monthly capacity is hard to plan around.

One framing that helps clients understand retainers: app maintenance costs roughly 15 to 20 percent of the original development budget annually, according to Imaginovation. That is not optional spending. Operating systems update, device dimensions change, third-party APIs deprecate, and user expectations shift. A retainer is one way to hold that cost steady rather than absorbing it as a series of emergency interventions.

The risk with retainers is scope drift in the opposite direction to fixed-price projects. Rather than scope being squeezed, it expands quietly. A client who feels they have monthly capacity available will fill it, sometimes with work that is not the highest priority. Good retainer agreements specify what the time is for and review that periodically.

Before signing a retainer, ask the agency to define what a typical monthly breakdown of hours looks like and what falls outside the retainer scope. The boundary between retainer work and a new project charge is where disagreements tend to start.

Discovery phases and why they are priced separately

A discovery phase is a structured period of research, definition, and planning that happens before any design or development begins. Its purpose is to understand what should be built, why, and for whom, before committing a larger budget to building it. Most agencies price discovery separately, typically as a fixed-fee engagement, because the outputs from discovery determine the scope, cost, and timeline of everything that follows.

Clients sometimes read a separate discovery fee as an upsell, an extra charge for conversations they feel they have already had. That reading misses what discovery produces. A ballpark estimate produced without discovery carries roughly plus or minus 50 percent accuracy. A proper discovery phase typically brings that down to plus or minus 10 to 20 percent, according to Devtimate. The difference between those two accuracy levels is the difference between a budget that holds and one that doubles.

What discovery actually does

Discovery maps user needs against business goals, identifies technical dependencies, flags risks early, and produces a specification detailed enough to quote from reliably. Without it, every estimate is a guess dressed up as a commitment, and the gap between the two surfaces later, always at a worse moment.

When clients come to us with a budget already agreed and a timeline already promised internally, the request that follows is often to skip discovery and start building. Our response is to explain that the discovery phase is what makes the budget and timeline mean anything. Without it, the number on the contract is a wish.

Without discovery, the number on the contract is a wish, and scope is defined by whoever shouts loudest mid-project.

We once declined a project involving a social product rebuild precisely because the client refused to engage with discovery. They wanted to go straight to redesign work. We walked away rather than start a project whose foundations we had no way to understand. That stance is grounded in experience: every project we have seen skip discovery has spent more correcting course than the discovery phase would have cost.

What a quote actually includes, and what it does not

A quote from a development agency is a price for a defined piece of work, and the definition matters as much as the number. Understanding what sits inside a quote and what sits outside it prevents the most common sources of mid-project friction.

The most common source of budget shock is scope that was implied but not specified. A client who expects user analytics built in, push notifications configured, and an admin dashboard included will find each of those is a separate line item if it was not named in the original brief. The remedy is to ask, before signing, for a list of what the quote does not cover.

Ask every agency to send you a written list of exclusions alongside their quote. A thorough exclusion list from an agency is a good sign, not a red flag. It means they have thought carefully about what you asked for.

How scope creep shifts cost and risk

Scope creep is the gradual expansion of a project's requirements after the work has begun. It rarely announces itself. A new feature gets added because a stakeholder feels it was always implied. A design gets revised because the original brief was interpreted differently from either side. A third platform gets requested because the launch date is slipping anyway and the time feels available. Each individual change seems small. The cumulative effect can be large.

We worked on a sports club app where scope creep was not gradual; it was constant and structural. The two co-founders were deeply embedded in the environment the app was designed for and both independently pushed to add features throughout the project, each convinced their additions were already implied by the original vision. Holding scope was extremely difficult when the clients themselves could not agree on what the scope was.

We warned the team early that the budget would spiral without intervention. The warning went unheeded. What should have reached market within three to four months never launched after twelve to fourteen months of development, and the budget almost doubled. Every additional feature deferred the launch and consumed the headroom that would have funded the next iteration. The project ended with the budget exhausted, nothing published to the App Store, and the relationship dissolved. The Standish Group's CHAOS Report found that 31.1 percent of software projects are cancelled before completion; this was one of them, and the cause was entirely preventable.

Agree a formal change-request process before the project starts. Every new feature or revision should go through a written request that captures the impact on timeline and budget. This protects both sides and keeps scope visible.

When a low quote is a warning sign

A quote that comes in significantly below others for the same brief is a signal that something in the calculation is different, and understanding what is different matters before accepting it.

We have seen competing quotes on projects that were unfeasibly low, too low to represent a credible commitment to the work described. When we looked more closely, the pattern was consistent: those agencies had asked very few questions before quoting. They had not dug into the brief, had not requested a call to clarify requirements, and had not mapped dependencies. They had taken the brief at face value and returned a number designed to win the work rather than to reflect the cost of doing it properly.

Where the difference appears

The gap between a low quote and a realistic one tends to surface in one of three places. The first is quality: the work delivered reflects the rate paid, with corners cut that are not immediately visible. The second is scope: the low quote covered a narrower interpretation of the brief, and everything outside that interpretation becomes a change request. The third is timeline: the project runs over, additional charges accrue, and the final cost lands close to or above the realistic quote that was rejected at the start.

McKinsey research found that 45 percent of IT projects exceed their budget, according to McKinsey. A low initial quote does not reduce that risk. It frequently increases it, because the contingency built into the number was never there to begin with.

How budget misalignment affects what gets built

Budget misalignment happens when a client's financial commitment and their product expectations do not match. It is one of the most common and most damaging dynamics in app development, and it usually becomes visible only after the project is underway.

We worked on a football-focused social media app where the client wanted an MVP-style initial release but had a budget that did not match the quality of experience they genuinely expected. A lower budget means less flexibility and a focus on getting to market quickly. That is a reasonable approach, provided both sides accept it. The problem on this project was that the client wanted the lower budget but not the constraints that come with it. We had multiple conversations trying to align expectations with the financial reality.

The project did reach a completed product, but with feature compromises. The client chose to allocate budget to areas the team considered lower priority, which meant features that would have had more impact on the user experience were deferred or cut. The product launched, but not the product either side had originally envisioned.

A budget sets a ceiling on what is possible in a given timeframe. The ceiling is not negotiable by expecting more from the team. It moves when the budget moves, or when the scope moves to match it.

Skipping discovery and what it costs later

The cost of skipping discovery does not show up on day one. It shows up when a feature built without adequate research contradicts the logic of the rest of the product, and a large section of work has to be rewritten from scratch.

We worked on a dating app built around verified profiles, with a rigorous onboarding process designed to prevent bots and fake accounts. The client chose to skip the discovery phase for the messaging component and focus the research budget on onboarding alone. The messaging feature was built using a generic approach, and that approach allowed automated and fake messages, directly undermining every verification decision made during onboarding.

The mismatch between the verified onboarding and the permissive messaging system meant the entire messaging section had to be rewritten. That rewrite cost approximately £15,000 in additional budget and two months of additional work. The discovery phase that was skipped would have cost a fraction of that and would have caught the contradiction before a line of code was written.

Projects that skip discovery are, according to Devtimate, three to five times more likely to fail or exceed budget. The dating app did not fail, but it absorbed a cost that was entirely avoidable and that set the launch back by two months. That delay has its own cost, in development resource, in marketing timing, and in the window of opportunity the product was built to address.

Discovery is priced separately because it is genuinely separate work. It is also the work that makes every subsequent decision cheaper and faster. Skipping it to save money at the start is one of the more reliable ways to spend more by the end.

Conclusion

App development pricing is not arbitrary. Each model, fixed-price, time-and-materials, or retainer, reflects a different allocation of risk and a different theory about what is knowable before work begins. Understanding which model fits your project is as much a design decision as choosing a navigation pattern or a colour palette, because the pricing structure shapes what gets prioritised, what gets cut, and what gets deferred.

The projects that go wrong tend to share common patterns. A brief that was too loose for fixed-price quoting. A scope that expanded without anyone formally agreeing to the cost. A discovery phase that was skipped to save money at the start. A low quote that looked like good value and turned out to be neither. None of these failures are inevitable, and none of them require extraordinary discipline to avoid. They require clear agreements, honest conversations about budget and constraints, and a willingness to do the foundational work before committing to the build.

Budget is a signal about what a project can realistically become, and working honestly within it is what produces products that actually reach users. If you are trying to understand what your project should cost, or why two quotes you have received look so different, let's talk about your app project.

Frequently Asked Questions