What an App Actually Costs: The Hours Behind Every Module

Most cost pages give you a single range for "a mobile app" and leave you to guess where your product sits inside it. That is not useful when the question you actually have is whether adding payments or offline mode is what breaks the budget.

So here is the whole model, module by module. These are the same numbers our cost calculator runs on, and they were calibrated against a real delivery: a platform that came in at 3,086 hours over 31 weeks with a team of five to six.

The base: what you get before any feature

Every project starts with work that belongs to no feature: architecture, the screen skeleton, build pipeline, environments, release setup. Skipping it in an estimate is the most common way 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 an existing product (agent, RAG or LLM workflow): 180 to 420 hours
• Design only (UX research through UI kit): 120 to 280 hours

The modules and what each one adds

Each of these is a self-contained piece of work with its own testing. The spread between low and high is not padding: it is the difference 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
• Content management: 70 to 140 hours
• Chat or messaging: 110 to 200 hours
• Video or media pipeline: 120 to 230 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
• Realtime or live events: 90 to 180 hours
• Offline mode and sync: 80 to 160 hours
• Multiple languages: 40 to 90 hours
• Compliance: GDPR, PCI, HIPAA: 80 to 200 hours
• Accessibility (WCAG): 60 to 130 hours
• Data migration from an existing system: 70 to 170 hours
• Performance and load work: 50 to 110 hours

Two of these deserve a note, because they are the ones people leave out and then discover.

Compliance is not paperwork. If you touch health data, card payments or public sector procurement, someone builds audit trails, consent flows and data retention rules, and then someone else reviews them. That is 80 to 200 hours of engineering, before any waiting.

Data migration is not a script. Moving from a system you already run means mapping a data model that was never designed for your new one, then handling the records that do not fit. The 70 to 170 hours is mostly the second part.

Why the modules do not simply add up

Add the base and the modules and you get a number that is always too low. Between the parts there is glue: shared state, permissions that cross features, end to end testing, the release cycle that belongs to no module.

So the model multiplies the sum by 1.25. That factor is not a safety margin and not optimism insurance: it was set so the model lands on the same size as a project we actually delivered, rather than on the smaller number you get by adding isolated modules. Integrating into systems you already run is a separate line, priced above as its own module.

From hours to a calendar

Hours become weeks through one more number: we plan about 18 focused hours per person per week, not 40. The rest goes to code review, handover, clarifications and releases.

Check it on the anchor project: 31 weeks x 5.5 people x 18 hours = 3,069 hours, against 3,086 actually delivered. Plan and outcome are 0.55 percent apart.

Three worked examples from the same model:

• Minimal mobile app with accounts: 570 to 950 hours, 11 to 18 weeks, two or three people
• Typical MVP (mobile, accounts, payments, admin): 860 to 1,490 hours, 10 to 17 weeks, two to five people
• Platform (mobile and web, eight modules): 1,730 to 3,150 hours, 16 to 29 weeks, three to six people

Notice that the MVP is not faster than the minimal app in calendar terms. More people work in parallel, so the weeks stay similar while the hours grow. That is the honest shape of it: parallel work buys calendar, it does not reduce work.

What is not in these numbers

• ongoing support and maintenance after launch
• infrastructure and hosting
• third-party licences and paid APIs

They are real costs, they just start when the build stops.

Run it on your own scope

Pick your product type and the modules you actually need in the cost calculator and it returns the hours, a realistic timeline and the team size, using exactly the numbers above. It takes about a minute and does not require a call.

If you want the reasoning behind the timeline, that is in how long it takes to build a mobile app. If you are holding a quote from someone else, how to read a development estimate lists the five questions that make two very different numbers comparable. Which of these modules gets discovered late, and what that costs, is in what actually goes wrong in app projects.

Questions people ask

Why do you publish hours instead of prices?

Because hours are the part we can state honestly for everyone. A price depends on the rate you agree, the mix of roles and where the work happens. The hours are the same regardless, and they are the number you can compare between vendors.

Is the low end of each range ever realistic?

Yes, when the module is genuinely simple and nothing else depends on it. Accounts at 60 hours is email and password with two roles. Accounts at 110 hours is single sign on, invitations, permissions that other features read, and the audit trail someone will ask for later.

What makes an estimate land above the high end?

Two things, in our experience. Requirements that keep moving after the build starts, and systems you already run that turn out to be undocumented. Neither is visible in a feature list, which is why discovery is worth buying before development.

Do these numbers include design?

Yes. Across our work the split is roughly 70 percent design and development, 15 percent QA and 15 percent project management, and the ranges above cover all three.