What an App Actually Costs: The Hours Behind Every Module

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): 120-220 hours
• Web app (Next.js, dashboard or SaaS): 100-200 hours
• Mobile and web together (shared backend, two clients): 200-360 hours
• AI feature inside an existing product (agent, RAG or LLM workflow): 80-200 hours
• Design only (UX research through UI kit): 80-180 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: 25-50 hours
• Payments and subscriptions: 30-70 hours
• Content management: 40-100 hours
• Chat or messaging: 35-70 hours
• Video or media pipeline: 45-100 hours
• AI: agent, RAG or generation: 80-180 hours
• Admin panel and analytics: 80-160 hours
• Third-party integrations: 25-70 hours
• Realtime or live events: 30-80 hours
• Offline mode and sync: 40-90 hours
• Multiple languages: 15-40 hours
• Compliance: GDPR, PCI, HIPAA: 40-100 hours
• Accessibility (WCAG): 30-70 hours
• Data migration from an existing system: 30-90 hours
• Performance and load work: 20-60 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 40-100 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 30-90 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.

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

The rest goes to code review, handover, clarifications and releases.

Plan and outcome are 0.55 percent apart.

Three worked examples from the same model:

• Minimal mobile app with accounts: 370-750 hours, 7-14 weeks

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.

Who Kultrix is behind these numbers

Kultrix, an agency in Lviv, Ukraine, builds web and mobile products end to end, with design, development, QA and project management in one team, and the module list above is the one in our public calculator. Every case study on our site lists the stages these modules turn into, from research and user flow through wireframes and UI design to development: Fitblast, an AI fitness app delivered as an MVP, is one to read through, and our MVP development page covers how we approach a first version.

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.

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.

Is the low end of each range ever realistic?

Yes, when the module is genuinely simple and nothing else depends on it. Accounts at 25 hours is email and password with two roles. Accounts at 50 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.

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.

Do these numbers include design?

Yes.

Design on its own is a product type in the Kultrix model rather than a line inside someone else's number - from research through a UI kit it is 80-180 hours - and the depth you pick multiplies the rest of the estimate instead of sitting beside it.