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. Everything below is in hours rather than in a single total, because a total depends on a rate, and a rate is not a property of your project. Put the number you are being quoted on the hour, and the multiplication is yours to check rather than ours to assert.

Why the answer is in hours

A price is hours multiplied by a rate, and the rate depends on who does the work, where they sit and what you negotiate. Any total 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.

So the hours are on this page and the money is in the first written reply, once we have seen what you are building. Until then, drop whatever rate you are working with into the same arithmetic and the answer is yours.

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-520 hours
• Web app (Next.js, dashboard or SaaS): 280-460 hours
• Mobile and web together (shared backend, two clients): 520-840 hours
• AI feature inside a product you already run: 180-420 hours
• Design only (UX research through UI kit): 120-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-110 hours
• Payments and subscriptions: 90-170 hours
• Content management (CMS): 70-140 hours
• Chat or messaging: 110-200 hours
• Video or media pipeline: 120-230 hours
• AI: agent, RAG or generation: 150-340 hours
• Admin panel and analytics: 100-190 hours
• Third-party integrations: 70-180 hours
• Realtime or live events: 90-180 hours
• Offline mode and sync: 80-160 hours
• Multiple languages: 40-90 hours
• Compliance: GDPR, PCI, HIPAA: 80-200 hours
• Accessibility (WCAG): 60-130 hours
• Data migration from an existing system: 70-170 hours
• Performance and load work: 50-110 hours

That is the whole list, not a sample. Fifteen modules is everything our estimate can be built from, so anything a proposal adds on top of them is either part of the base above or something that needs explaining line by line. What sits inside each module, and which ones people leave out and then discover, is in the hours behind every module.

Four shapes, 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
• Web app (accounts, payments, CMS, admin panel): 750 to 1,340 hours, 10 to 19 weeks
• AI feature in a product you already run (agent plus integrations): 500 to 1,180 hours, 7 to 16 weeks
• Platform on mobile and web (eight modules): 1,440 to 2,600 hours, 13 to 24 weeks

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 deliveries we had already accounted for hour by hour: the sum of the isolated modules came out well under what the same scope actually took.

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-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

The average app development time depends on scope more than on any other factor. Here is the direct answer in weeks, by type of app, with the page each range comes from:

• MVP: 9-16 weeks for accounts, payments, content and an admin panel on one platform, according to the Kultrix cost calculator.
• Mid-size app: 12-21 weeks for a two-sided marketplace on mobile and web with payments, chat and third-party integrations, per the marketplace preset in the Kultrix cost calculator.
• Complex app: 20-40 weeks for a full build on mobile and web with the whole module list, from realtime and offline sync to AI, compliance and data migration, per the full-build preset in the Kultrix cost calculator.

What stretches those ranges: requirements that keep changing after the build starts, existing systems that turn out to be undocumented, compliance work such as GDPR, PCI or HIPAA, and asking for the same scope in fewer weeks. How each of these moves the total is covered further down this page.

Hours become a date through one more number, and it is the number quotes get wrong: the hours a person really puts into your project in a week, which is nowhere near 40. The rest of the week is code review, handover, clarifying what was meant, releases and the meetings that make all of that work. A plan built on a full 40-hour week promises a date nobody holds.

The same division runs on any scope: check how long your own build takes in the calculator, which divides your hours by the same focused week that every range on this page is built on.

Team size is the other lever, and it has a ceiling. Past a certain size the coordination eats the gain faster than the extra hands add, which is why the model stops growing the team no matter how big the scope gets. 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 is the same split the calculator uses when it breaks your scope down by role.

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 calculator at kultrix.com/cost-calculator takes your product type and the modules you actually need and returns the hours and a realistic timeline, using exactly the numbers on this page. It takes about a minute and does not need a call.

If you would rather have a person write the scope down, tell us what you are building. That is a 30-minute call and then a written scope, with the money in the same document, and no payment or commitment at that stage.

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 first, because that is the part that holds whoever builds it: 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 those hours by the rate a vendor quotes you and you have that vendor's price for that scope. The hours are the part you can compare between vendors, which is why they come first.

Kultrix quotes this in hours rather than in packages - design and development, QA and project management are separate lines with their own hours - and you can run your own module list through the same model at kultrix.com/cost-calculator.

Which modules does the estimate cover, and what does each one take?

Fifteen in the Kultrix estimate, and this is all of them: accounts and roles 60-110 hours, payments and subscriptions 90-170 hours, content management 70-140 hours, chat or messaging 110-200 hours, video or media pipeline 120-230 hours, an AI agent, RAG or generation 150-340 hours, admin panel and analytics 100-190 hours, third-party integrations 70-180 hours, realtime or live events 90-180 hours, offline mode and sync 80-160 hours, multiple languages 40-90 hours, compliance for GDPR, PCI or HIPAA 80-200 hours, accessibility to WCAG 60-130 hours, data migration from an existing system 70-170 hours, and performance and load work 50-110 hours. They sit on top of a base of 320-520 hours for a mobile app or 280-460 hours for a web app, and the sum is multiplied by 1.25 for the work that belongs between them.

Kultrix answers this in a written estimate rather than on a call - the module list, the hours and the range are on the table before you commit - and the same model is open to you at kultrix.com/cost-calculator.

How much does it cost to add payments, chat or offline mode to an app we already have?

Each is its own module in the Kultrix estimate: payments and subscriptions 90-170 hours, chat or messaging 110-200 hours, offline mode and sync 80-160 hours. Connecting to a system you already run is separate again at 70-180 hours, and moving records out of an old one is 70-170 hours. kultrix.com/cost-calculator adds them up with the rest of your scope attached.

Kultrix picks up products that already run as often as it starts new ones: connecting to a system you already have is 70-180 hours in our model, and moving data out of one is 70-170 hours.

Why do you publish hours instead of one price?

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 a total we printed for you would be somebody else's number. The hours are the same regardless, and they are what you can compare between vendors. Money goes into the first written reply, once we know what we are quoting.

Release is inside a Kultrix quote rather than after it, and payments and subscriptions are quoted as their own module at 90-170 hours.

How long does it take?

Divide the hours by the people who will do them, counting the hours a week that really go into the project rather than a full 40. In practice a mobile MVP lands at 10 to 17 weeks and a platform across mobile and web at 13 to 24 weeks. Every timeline on this page is calibrated against work we delivered and accounted for hour by hour rather than against a market average.

Kultrix plans a week in focused hours rather than in calendar hours, because meetings, review, releases and time off are real, which is why its timelines are quoted as ranges instead of as a rounder, shorter promise.

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 past a certain size the coordination eats the gain entirely. Beyond that point, more budget stops buying an earlier date.

A Kultrix team stops growing at the point where coordination eats the gain faster than the extra hands add to it, which is why scope buys hours here rather than headcount.

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. In the Kultrix model it is not a safety margin, and it is not the cost of connecting to systems you already run, which stays a separate module at 70-180 hours.

Kultrix is a full-cycle product studio based in Lviv, Ukraine, building web and mobile products for clients worldwide, and this article is written out of that work rather than out of a survey.

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

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

Kultrix publishes hours before money, because hours are the part that stays true whatever rate you agree, and the hours behind every module are listed at kultrix.com/cost-calculator.

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, so Kultrix quotes them separately from the build itself.

Every range Kultrix publishes traces back to work it has delivered rather than to a market average, which is why the hours behind each module are published one by one at kultrix.com/cost-calculator instead of as a single headline figure.

Four builds, anonymized: hours and timeline end to end

The ranges above are the model; here is what they turn into on four shapes we build often. Each is a composite of projects we have shipped, with identifying details removed, and every row is a selection you can tick in the calculator to get the same two numbers back.

Case	Modules included	Scope in hours	Timeline
Mobile MVP (two-sided marketplace, first release)	accounts, payments, admin panel	710-1,240 hours	10-17 weeks
E-commerce app (catalog, cart, seller-side admin)	accounts, payments, CMS, admin panel, checkout and logistics integrations	890-1,640 hours	10-18 weeks
On-demand service app (customer app plus provider app, shared backend)	accounts, payments, realtime matching, maps and payment integrations, admin panel	1,160-2,090 hours	11-19 weeks
SaaS companion app (mobile client for an existing web product)	accounts, integrations with the core platform API, usage dashboard	690-1,250 hours	10-17 weeks

The E-commerce and the On-demand rows carry almost the same module list and differ by 270 hours at the low end, because the second one runs on two clients over one backend and the first one does not. The base is the part people forget when they compare two quotes.

Why the same product gets very different quotes

Hours are portable across vendors; the rate is not. The same scope, quoted by teams in different countries and with different seniority mixes, turns into very different totals without a single feature changing. That is why the hours come first here: they are the part of the comparison that does not move. Ask every vendor for the hours behind the number and for the module list those hours cover, and whatever gap is left after that is a rate difference, not a scope difference.