How much does it cost to build an app, and why I quote a fixed price

How much it costs to build an app, a web platform or an AI chatbot is the first question anyone who builds digital products gets asked, and the one that gets the worst answers. You will not find a dollar figure here, because it does not exist before we define what gets built; you will find what can be known beforehand: what the price depends on, how many weeks it usually takes, and how to read a quote. The honest answer is “it depends on the scope”, which sounds evasive until you understand exactly what it depends on. In this article I explain the variables that move the price, why I do not give a number before defining what will be built, and how I quote: a fixed price in writing for the first version, and hourly for the work that cannot be bounded. The goal is for you to be able to read any quote, mine or someone else’s, and know what you are being sold.

TL;DR

• The price of a digital product depends on how many flows it has, what backend it needs, which services it integrates with, whether it ships to the app stores and whether it includes AI. Not on the technology it is written in.
• A number given before the scope is defined is a guess. That is why the first step is a 30-minute call and a written proposal, at no cost if you decide not to go ahead.
• I quote a fixed price for the first version because the scope has already been defined and the risk of estimating wrong is mine. The audit and the maintenance are hourly, because there the scope cannot be pinned down in advance.

In this article:

• Fundamentals — What drives the price · Why I give no number without a scope · Fixed price or hourly
• The process — How the quote comes together · What it includes and what it does not · When the scope changes
• Comparing — How to compare quotes · What makes a project cost more

How much does it cost to build an app: what drives the price

The price of a digital product is, for the most part, the time of one person with judgment. What makes that time grow is the number of different things the product has to do well. These are the variables I look at before quoting any project, and they explain almost all of the difference between one quote and another:

Variable	What makes it grow	Example
Flows and screens	Every complete journey a user can take	Sign up, search, book and pay are four flows, not one app
Backend and data	Whether it needs its own server, a database and business rules	A read-only catalog is cheap; an inventory several people edit at once is not
Integrations	Every external service the product has to talk to	Payments, push notifications, maps, email, invoicing, a system you already have
Publishing	Whether the product goes to the app stores	Accounts, Apple and Google review, signing, and going through it again with every release
AI	Whether a language model answers real users	It has to be evaluated before it goes in front of real users, and you have to decide what it does when it is wrong
Design	Whether a Figma design exists or the interface still has to be defined	Building on a finished design is faster than deciding it while coding
What already exists	Whether you start from zero or from a product in use	An inherited product is quoted after I have read it, not before

Two of those rows tend to surprise people. The first is publishing to the stores: Apple and Google review is work with its own timelines and rejections, and it repeats with every version. The second is AI: a chatbot that answers well in the demo and badly in front of a real customer is worse than no chatbot, and avoiding that costs evaluation time you never see in the interface.

What does not move the price, or moves it far less than people think, is the list of technologies. Whether the app is written in React Native or in Swift changes important decisions, but it does not change the fact that sign up, search, book and pay are four flows that have to be built and tested.

What I can say before the call are the ranges that come out of my own work. A focused first version of a mobile app or a web platform, with one core flow, real data and a polished interface, usually takes 4 to 8 weeks of full-time work. An AI feature on top of a product that already exists, such as a RAG chatbot or a generation flow, usually ships in 2 to 5 weeks. Larger products, such as a streaming or healthcare platform, are planned in phases and each phase is quoted separately. Those weeks are what gets quoted: the price in the proposal is that time, locked in writing, and with any market rate you know you can work out an order of magnitude before you write to me.

Why I do not give you a number before defining the scope

When someone writes to me with “I want an app like X, how much does it cost?”, the right answer is not a number, and that is not a sales tactic. It is because the number does not exist yet. “An app like X” describes a product that took its owner years and several teams; the useful question is which part of X your business needs in the first few months, and that part can only be defined by talking.

A number given before that conversation has only one possible origin: someone guessed it. And guesses in quotes have a well-known property: when they are low, the project corrects them later with delays, arguments or features that quietly disappear. In the code audit for an inherited product I wrote the same thing from the other side: nobody can truly quote code they have not read.

Fixed price or hourly: when I use each one

I do not charge for everything the same way, and there is only one criterion for choosing: if the scope can be pinned down before we start, the price can be fixed too. If it cannot, charging a fixed price would be pretending to a certainty I do not have.

Type of work	How it is charged	Why
First version of a product (app, platform, chatbot)	Fixed price, split into milestones	The scope was defined beforehand; the risk of estimating wrong is mine, not yours
Audit of an inherited product	Hourly, capped at one week	I do not know what I will find until I read it; what can be bounded is the time
Maintenance and evolution after launch	Hourly, within a monthly agreement with a weekly cap you set	The work depends on what happens with real users, and that is not known in advance

A fixed price has a consequence worth understanding: if I estimated wrong and the first version takes longer than planned, that cost is mine. That is why the scoping phase exists and why I take it seriously: it is what lets the price stay put. That price includes the cost of carrying the risk; it is higher than the sum of hours if everything went perfectly, and in exchange it does not change when things do not go perfectly. And that is why hourly billing is neither worse nor better: it is the right way to charge when the work, by its nature, cannot be bounded before it starts.

When the contract runs through Upwork, this split already exists on the platform: fixed-price contracts with the money held in escrow per milestone, and hourly contracts with a work diary and a weekly limit. I explain it in why hiring through Upwork protects the client.

How the quote comes together in ten days

This is the path from your first message to the first week of work, in the order it happens:

The day-3 call is what decides how much the project ends up costing. It is the moment we decide what not to build yet, and that is the decision that saves the most, as I explained in what a product engineer is.

A quote that arrives without the call had nowhere to get the scope from: the number was set by whoever wrote it, not by the product.

The day-5 proposal is the same document that later becomes the shared timeline. The milestones in it, with their dates, are the ones I mark every week as done or moved, and if something moved I write down why.

What the quote includes and what it does not

A fixed-price quote is only useful when it is clear what it buys. What mine includes for a first version:

• The product working and published. The app in the stores or the platform live, not a repository that “just needs deploying”.
• Something you can open every Friday. A build on your phone or a URL, with a progress note in plain language. In how I work I describe that week.
• Complete engineering. Tests, code review and continuous integration are included; they are what keeps version two from costing twice as much. With a fixed price, the provider’s temptation is to cut where it does not show; the Friday demo and the included tests are what makes that cut visible.
• Everything in your name. The repository in your GitHub account, the store, domain and hosting accounts in your name, and enough documentation for another developer to carry on.

What it does not include, and what is worth keeping in mind before comparing:

• Third-party costs. The Apple developer account has an annual fee and the Google one a one-time fee; hosting, the database, email delivery, maps and calls to AI models are paid to the provider, in your name, by usage. I list them in the proposal so they do not show up as a surprise, but they do not go through me.
• Content and brand. The copy, the photos, the logo and the visual identity are yours or a designer’s. I build on top of that.
• What was left out of the scope. Everything we decided on the call to leave for later stays out, in writing; that trimming is what makes it possible to fix the price.

What happens when the scope changes mid-project

A scope change mid-project is handled in writing, in the weekly meeting, and ends in one of three situations depending on its size. It will happen: a product is understood better once it can be opened, and each week’s demo produces ideas the initial call could not. A fixed price does not freeze the scope; it forces changes to be recorded instead of absorbed in silence.

The three situations:

The change	What happens to the price and the timeline
It is a detail within what was agreed: a text, a color, the order of a screen	It goes in at no cost, in the current week or the next
It replaces something of similar size that has not been built yet	It is swapped, recorded in the meeting notes, and the dates hold as long as the size really is similar; if it is not, it moves to the next row
It is new and adds work: a screen, an integration, a user role	It is quoted as an additional milestone and you decide whether it goes in now, after launch or never

The third row is what avoids the two well-known ways of ruining a fixed-price project: the developer accepts everything and the timeline falls apart, or rejects everything and the product ships without what you learned along the way. The weekly meeting is where that decision is made, with the demo in front of us, and the three-line notes are where it is recorded. And if at some point you want to stop, the natural stopping point is the end of a milestone: what was delivered is already yours and what was not started is not paid for.

How to compare quotes that look nothing alike

If you asked for three quotes and they came back with very different numbers, the most likely explanation is that they did not quote the same thing. Before comparing prices, compare this:

1. What scope was quoted? If there is no document with the flows that are in and the ones that are out, each provider imagined a different product. Ask them to quote on the same text.
2. What does “done” include? Published to the stores, with tests, with the accounts in your name, or “ready to deploy”. Those are four different prices.
3. How is a change handled? If the answer is vague, the fixed price will stop being fixed in week three.
4. What happens if it takes longer than planned? With a fixed price, that risk is the provider’s. If the quote is “estimated” or “approximate”, the risk is yours and the number is, in practice, an hourly rate that is not being said out loud. If the contract also runs through Upwork, your money is held in escrow per milestone and only released when you approve the delivery; in why hiring through Upwork protects the client I explain how that protection works.
5. How many people sit between you and whoever writes the code? Every intermediary costs, in money and in decisions that arrive late.

On comparing by the hour: the hourly rate is the easiest thing to compare and the one that tells you the least. Someone who charges less per hour and needs twice the hours, or builds what was not needed, ends up costing more. The comparison that works is the cost of the whole project: it includes the hours that were never needed because something was not built, and the ones that did not have to be redone.

What makes a project cost more than quoted

With a fixed price, what raises the cost is not the time it takes me, it is what gets added to the scope. And it almost always gets added for one of these reasons, all of them avoidable:

• Nobody can decide within 48 hours. Every week needs small decisions, and if they wait for a committee to meet, the timeline moves and the product fills up with assumptions that later have to be undone. That is why I ask for one person with decision-making power from the start.
• Access arrives late. Store accounts, domains, a system that has to be integrated. If they are created in week four, week four is lost.
• Everything has to go into the first version. It is the most common reason and the most expensive one. Every flow added on the initial call gets quoted, but every flow added “while we’re at it” gets quoted separately, with the timeline already running, and costs more because it interrupts what was already planned.
• The content is not ready. Copy, images, real data. An app without its data cannot really be tested, and testing with made-up data hides the problems that later show up in production.
• The project inherits code nobody has read. If the product starts from existing code, quoting it without auditing it first is the surest way to get it wrong. That is why the audit comes first and is hourly.

None of those causes sits in the technical part. They sit in how the project is organized, and that is where a client has more control than they think over what they end up paying.

Frequently asked questions

How much does it cost to build a mobile app?

Mobile app development cost depends on the scope: how many flows it has, whether it needs its own backend, which services it integrates with and whether it goes to the stores. A focused first version, with one core flow, real data and a polished interface, usually takes 4 to 8 weeks of full-time work, and the price is quoted per project after a 30-minute call that defines that scope. Nobody can give a serious number before that conversation, because the product to be quoted is not defined yet.

Why do you charge a fixed price instead of hourly?

I charge a fixed price for the first version because the scope is defined before we start and, once defined, the risk of estimating wrong should sit with the provider, not the client. With a fixed price, if the work takes longer than planned, that cost is mine. Charging hourly for a scope that is already fixed shifts that risk onto the client without giving them anything in return. I only charge hourly for what cannot be bounded in advance: the audit of an inherited product and the maintenance after launch.

What happens if the project takes longer than quoted?

If the scope has not changed, the price does not change either: the extra time is my cost. If the scope changed because you added something new, that change was quoted as an additional milestone at the moment you asked for it, in writing, and you decided whether it went in. What does not happen is the price going up at the end for reasons nobody recorded during the project.

Does the quote cost anything?

No. The 30-minute call and the written proposal with scope, milestones, dates and price are part of deciding whether we work together, and if you decide not to go ahead they cost you nothing. What does cost something, and is hourly, is the audit of a product that already exists, because there the quote requires reading the code and that is a real week of work.

Can I pay in installments?

Yes: the fixed price is paid per milestone of one or two weeks, each with a delivery you can open and test before approving it. If the contract runs through Upwork, the money for each milestone is held in escrow until you approve the delivery; if it is direct, each milestone is paid against the same delivery. In both cases, what you approve at the milestone is what you already saw working in the weekly demo.

Which costs are not in the quote?

The ones paid to third parties by usage and in your name: the Apple and Google developer accounts, hosting, the database, email delivery, maps, payments and calls to AI models. Also content and brand: copy, images, logo and visual identity. In the proposal I list the services the product will need so they do not show up as a surprise, but they are contracted directly by you as the account holder.

Conclusion

The price of a digital product comes from its scope, and the scope does not exist until someone with technical judgment defines it with you. That is why a serious quote starts with a conversation and ends with a document, and that is why a fixed price is possible: not because the work is predictable, but because the risk of estimating it wrong sits with the person who has the information to estimate it. What cannot be bounded in advance, such as reading someone else’s code or maintaining a product in use, is charged hourly, and saying so clearly is part of quoting well.

If you are about to ask for quotes, do this in order: write on one page what the first version has to do and what can wait, even if it comes out incomplete; ask that every quote be made on that same text; ask each one what “done” includes, how a change is handled and who carries the risk if it takes longer. With the same scope and those three answers, the numbers that looked nothing alike start to become comparable. And if you would rather start with the conversation, how I work describes what happens from your first message to the proposal.