InterLAB's references: a mobile app MVP is 2–5 million ₸ and 6–12 weeks, a turnkey app is 5–15 million ₸ and 2–4 months, complex products with many roles and integrations start from 10 million ₸ and take 4–8 months. The price isn't driven by the "number of screens" but by scenarios, the backend, integrations and the number of platforms. Budget separately for recurring costs: developer accounts in the stores, the server and maintenance.
Contents
Budget and timeline references
Let's start with the numbers, since that's the question. These are InterLAB's public ranges — a scale reference, not a price list: the exact fixed price is named after the brief, once the scenarios and integrations are clear.
2–52–5
million ₸ — app MVP, 6–12 weeks
5–155–15
million ₸ — turnkey app, 2–4 months
10+10+
million ₸ — complex products, 4–8 months
22
weeks to a clickable prototype
The spread within a range comes down to scope: the same "delivery app" can be a storefront with ordering across a couple of screens, or a product with a courier app, tracking, payments and a partner account. These are different projects, even though they're described the same way in an email.
What the price is made of
A mobile app isn't just what you see on the phone screen. Beneath the interface sit the server, the admin panel and connections to other systems, and in the estimate these are separate blocks of work:
Interface
- What's included
- screens for the core scenario, states, adaptation to screen sizes
- What makes it more expensive
- custom animation, different screens for different roles
Server and API
- What's included
- data, authorization, business logic
- What makes it more expensive
- complex calculations, real-time features, load
Admin panel
- What's included
- managing content, orders, users
- What makes it more expensive
- flexible reporting, granular access permissions
Integrations
- What's included
- payments, notifications, 1C, CRM, maps
- What makes it more expensive
- each external system is a separate block of work
Publishing
- What's included
- preparing for App Store and Google Play review
- What makes it more expensive
- repeat reviews if a store sends the app back
The practical takeaway: two estimates for an "app with 20 screens" can differ several times over and both be honest. Compare not the totals but what goes into each layer.
One platform or two
The question with the biggest effect on the budget is how many platforms to build for, and how. There are two main paths:
Separately for iOS and Android
- Two codebases: every feature is written and tested twice
- Maximum access to each platform's capabilities
- Justified for heavy graphics and deep hardware work
- More expensive to maintain over time
Cross-platform (React Native)
- One codebase: shared logic is written once
- Most business scenarios are covered without compromise
- Platform-specific features may require native modules
- Easier for one team to develop and maintain
Implementation options and how they affect the budget
The same task can be solved in different technical ways, and each has its own cost structure — not only for development but also for support in the following years.
PWA (web app)
- When it fits
- no need for the stores; a browser and an install-to-home-screen are enough
- What matters for the budget
- one codebase with the website, updates without review; limited device access
Cross-platform (React Native, Flutter)
- When it fits
- most business tasks for iOS and Android
- What matters for the budget
- one codebase and one team for two platforms; native modules as a separate line
Native development (Swift + Kotlin)
- When it fits
- the product is built around platform capabilities
- What matters for the budget
- two codebases — two builds and two support lines
Single-scenario MVP
- When it fits
- you need to validate demand before the full budget
- What matters for the budget
- a smaller starting scope; the first version's scope is fixed in advance
Recurring costs after launch
Development is a one-off payment, but the app lives on. Here's what to budget for in advance:
- Apple Developer Program membership — 99 USD per year (the amount in local currency may differ)
- Google Play registration — a one-time fee of 25 USD
- Server and infrastructure: hosting, database, backups
- Updates for new iOS and Android versions — the stores periodically tighten their requirements
- Third-party services: SMS, push notifications, maps, payment fees
- Growth: new features based on post-launch data
The store fees are fixed and listed on the official Apple and Google pages (links at the end of the article). The other costs depend on load and the services you choose — we list them as a separate line in the estimate.
Common budget mistakes
Budgets most often fail not because development is expensive but because part of the work was not visible in the first estimate.
- Counting only screens and forgetting the server, API and admin panel — without them the app has nothing to show
- Postponing integrations: payments, 1C and a CRM cost more to add later than to plan into the architecture
- Ignoring recurring costs: store accounts, the server, monitoring and updates for new OS versions
- Starting with the full version instead of an MVP — and spending the budget on features users don't use
- Not allowing for repeated store reviews: Apple's and Google's remarks require fixes and time
- Comparing proposals with different scope: one includes design, testing and publishing, another does not
The protection against these mistakes is a brief listing scenarios, roles and integrations before talking about price: then estimates from different vendors can be compared by scope, not only by the final number.
How to get an exact estimate
Brief
We unpack the idea, the users, the scenarios and the integrations. No need to prepare a spec — we'll fill in part of it with questions.
Itemized estimate
An estimate by stage: what goes into the first version, what's postponed, what maintenance costs.
Prototype
Clickable key screens — changes on a mockup are many times cheaper than changes in code.
Fixed MVP price
Scope and price are fixed, with payment in two steps: at the start and at release.
Budget is a function of scope: by cutting what's non-critical from the first version, you lower the price in a controlled way, not at the expense of quality.
