How Much Does an App Cost, and How Long Does It Take?

Two questions arrive in the first email, always in this order: what will it cost, and when can we launch. Most agency sites answer with a range wide enough to be useless, or with a contact form. This page is our real answer, with the arithmetic left visible so you can check it.

One thing up front. We publish hours, not prices, and that is a deliberate limit rather than coyness.

Why the answer is in hours

A price is hours multiplied by a rate, and the rate is not a property of your project. It depends on who does the work, where they sit and what you negotiate. Any figure we printed here would either belong to somebody else's project or be one we would have to walk back on the first call, and a number you have to walk back is worse than no number at all.

Hours we can state for everyone. They are also the part that makes two proposals comparable: put two quotes side by side, strip the rates out, and the hours tell you which team understood the scope and which one guessed.

What it costs: the hours behind a build

Every project carries work that belongs to no feature: architecture, the screen skeleton, environments, build pipeline, release setup. That is the base, and leaving it out is the most common reason a quote looks cheap.

• Mobile app (React Native or native iOS): 320 to 520 hours
• Web app (Next.js, dashboard or SaaS): 280 to 460 hours
• Mobile and web together (shared backend, two clients): 520 to 840 hours
• AI feature inside a product you already run: 180 to 420 hours
• Design only (UX research through UI kit): 120 to 280 hours

Features are then added as modules. Each one is a self-contained piece of work with its own testing, and the spread between the two ends is not padding: it is the gap between the simple version and the one that survives real users.

• Accounts and roles: 60 to 110 hours
• Payments and subscriptions: 90 to 170 hours
• Chat or messaging: 110 to 200 hours
• AI: agent, RAG or generation: 150 to 340 hours
• Admin panel and analytics: 100 to 190 hours
• Third-party integrations: 70 to 180 hours
• Compliance: GDPR, PCI, HIPAA: 80 to 200 hours
• Data migration from an existing system: 70 to 170 hours

That is the short list. The full one, with offline mode, video, realtime, accessibility and the rest, is in the hours behind every module.

Four shapes, priced end to end

Numbers per module are hard to feel. Here is what they add up to for four common shapes, each with custom design at a standard pace, straight out of the same model:

• Mobile MVP (accounts, payments, admin panel): 710 to 1,240 hours, 10 to 17 weeks, two to four people
• Web app (accounts, payments, CMS, admin panel): 750 to 1,340 hours, 10 to 19 weeks, two to four people
• AI feature in a product you already run (agent plus integrations): 500 to 1,180 hours, 7 to 16 weeks, two to four people
• Platform on mobile and web (eight modules): 1,440 to 2,600 hours, 13 to 24 weeks, three to six people

Notice that the MVP and the web app take about the same calendar time despite different totals. Extra people work in parallel, so the weeks hold while the hours grow. Parallel work buys calendar; it does not reduce work.

Why the parts do not add up to the total

Add the base to the modules and you get a number that is always too low. We know how much too low, because we checked the model against a delivery we had already accounted hour by hour: adding isolated modules gave a ceiling of 2,330 hours where the real project was 3,086.

Between the parts there is glue that belongs to no part: shared state, permissions that cross features, end to end testing of paths that touch several modules at once, and the release cycle. So the model multiplies the sum of the parts by 1.25.

Two things that multiplier is not. It is not a safety margin, and it is not what you pay for connecting the product to systems you already run. That second one is its own module, third-party integrations at 70 to 180 hours, and it is picked separately because plenty of projects do not need it at all. If someone tells you a blanket uplift covers your ERP or your existing billing, ask which line item that work sits in.

How long it takes: hours into a calendar

Hours become a date through one more number, and it is the number quotes get wrong: we plan about 18 focused hours per person per week, not 40. The rest of the week is code review, handover, clarifying what was meant, releases and the meetings that make all of that work. Anyone planning on 40 is promising a date they cannot hold.

Check it against the anchor: 31 weeks times 5.5 people times 18 hours is 3,069 hours, against 3,086 actually delivered. Plan and outcome are about half a percent apart.

Team size is the other lever, and it has a ceiling. Above roughly six people the coordination eats the gain faster than the extra hands add, which is why the model never staffs past six no matter how big the scope. Beyond that point, more budget stops buying an earlier date.

The longer version of this, including what actually moves a launch date, is in how long it takes to build a mobile app.

Where the hours go

Across our projects the split is roughly 70 percent design and development, 15 percent QA, 15 percent project management. It comes from the shape of the anchor team: one manager, one designer, two or three developers, one tester, over 31 weeks.

This matters when you compare quotes. An estimate with no QA and no management line is not cheaper, it just moved that work into your calendar. Someone still writes the test cases and chases the answers; the only question is whether it is a person on the project or you.

What moves the number, up and down

Three levers change the total without changing a single feature in the list.

• Design depth. Working inside an existing design system takes the whole build to 0.85 of its baseline. Custom design is the baseline, where most projects land. A signature identity with motion, illustration and brand work multiplies by 1.3, because that depth spreads into layout, states and animation across every screen rather than sitting in one line.
• Compressed delivery. Asking for the same scope in fewer weeks multiplies the hours by 1.2. Compression does not make the work smaller, it makes it more expensive: more people in parallel, more coordination, more rework.
• Scope clarity. The single biggest mover is not in any list. Requirements that keep changing after the build starts, and systems you already run that turn out to be undocumented, are what push a project past its high end. That is why discovery is worth buying before development rather than discovering it during.

What the hours do not include

• support and maintenance after launch
• infrastructure and hosting
• third-party licences and paid APIs
• app store fees and marketing

They are real costs. They just begin when the build stops, and they scale with usage rather than with scope.

Get the number for your own scope

Reading ranges is slower than picking your own. The cost calculator takes your product type and the modules you actually need and returns the hours, a realistic timeline and the team size, using exactly the numbers on this page. It takes about a minute and does not need a call.

If you are already holding someone else's quote, how to read a development estimate lists the five questions that make two very different numbers comparable. And if you want to know which parts of a project tend to be discovered late, and what each one costs in hours when it is, that is in what actually goes wrong in app projects.

Questions people ask

How much does it cost to build an app?

In hours, which is the part we can state honestly: a mobile MVP with accounts, payments and an admin panel is 710 to 1,240 hours, and a platform across mobile and web with eight modules is 1,440 to 2,600 hours. Multiply by the rate you agree with whoever builds it and you have the price.

Why do you publish hours instead of prices?

Because a rate is not a property of your project. It depends on who does the work, where they sit and what you negotiate, so any price we printed would be somebody else's. The hours are the same regardless, and they are the number you can compare between vendors.

How long does it take?

Divide the hours by the team, at about 18 focused hours per person per week rather than 40. In practice an MVP lands at 10 to 17 weeks and a full platform at 13 to 24 weeks. Our anchor project ran 31 weeks with a team of five to six.

Can we go faster by paying for a bigger team?

Up to a point. Compressing the calendar multiplies the hours by 1.2, because parallel work costs coordination and rework, and above roughly six people the coordination eats the gain entirely. Past that, more budget stops buying an earlier date.

What does the 1.25 multiplier cover?

The glue between modules: shared state, permissions that cross features, end to end testing and the release cycle, none of which belongs to any single module. It is not a safety margin, and it is not the cost of connecting to systems you already run.

Does the estimate include connecting to the systems we already run?

Only if you select it, because it is a separate module: third-party integrations at 70 to 180 hours, with data migration from an existing system at 70 to 170 hours when records have to move. Both are picked per project, since many builds need neither.

What is not included in the hours?

Support and maintenance after launch, infrastructure and hosting, third-party licences and paid APIs, and app store fees. Those costs start when the build stops and scale with usage rather than with scope.