The short answer
In practice, the price of a mobile app is the number of working hours multiplied by the team's rate. The hours depend on how many screens and features the app has, whether it needs its own server and admin panel, which systems it has to connect to and how many platforms we build it for.
That's why two "booking apps" can differ in price several times over. One is a calendar with a form, the other a system with payments, notifications, staff accounts and an integration with accounting.
Rough price ranges
The ranges below are typical market ranges for Polish software houses, not a price list. They're meant as a first orientation – a real figure can only be given after talking through the scope.
| Type of app | Example | Rough cost |
|---|---|---|
| Simple | a few screens, sign-in, content from an existing API | from several tens of thousands of PLN |
| Medium | user accounts, payments, push, admin panel | from around PLN 100,000 |
| Complex | marketplace, real time, many roles and integrations | several hundred thousand PLN and more |
Be wary of offers that quote a price for a "finished app" after a one-sentence description. Either the scope is very narrow, or the difference will surface during the project.
What affects the price most
Number of screens and features
Every screen has to be designed, coded and tested. But screens aren't equal: a product list takes a few hours, a basket with discounts, delivery and payment takes a few days. The logic costs the most, not the number of views.
Backend and admin panel
Most apps need a server: a place where accounts, data and orders are kept. On top of that there's usually a browser-based panel where you or your staff manage content. The backend and panel can be half the budget – worth remembering when comparing offers. In practice the panel is a separate web app.
Integrations
Payments, maps, calendars, ERP and CRM systems, courier companies, sign-in with Google or Apple. Ready-made, well-documented integrations are cheap. Old systems without a proper API can eat up more time than the rest of the app.
Platforms: iOS, Android or both
An app for both platforms built with a cross-platform technology (e.g. React Native) usually costs much less than two separate native apps. We cover this in more detail in the article React Native or a native app.
Visual design (UI/UX)
A ready-made component system is cheaper than a design from scratch with custom animations. Good UX design isn't "cosmetics", though – it decides whether users stay with the app after the first launch.
Testing, release and maintenance
Testing on different phones, preparing store descriptions and screenshots, getting through Apple and Google review. Then come updates for new system versions – details in the guide to publishing an app in the App Store and Google Play.
Costs that are easy to forget
- developer accounts in the App Store (annual fee) and Google Play (one-off fee),
- servers and cloud services – database, file storage, sending notifications and emails,
- paid APIs – maps, text messages, AI models, payment gateways (transaction fees),
- maintenance – market practice puts it at somewhere between the mid-teens and the mid-twenties per cent of the build cost per year for updates, fixes and minor development.
Fixed price or hourly billing?
Fixed price gives a predictable budget, but requires a very precisely described scope. Every change along the way means an annex and an extra charge, and the contractor builds a risk buffer into the price.
Time & materials (billing for the hours actually worked) is flexible: you can change priorities after every stage. It does, however, require trust and regular insight into progress.
In practice a combination works well: a fixed price for a well-defined first stage (e.g. design and prototype), then work in sprints with a budget per stage.
How to lower the cost of an app – without lowering quality
- Start with an MVP – a first version with the features that are really needed at launch. We explain how to plan it in the article App MVP.
- Choose cross-platform if the app doesn't need advanced hardware features.
- Use ready-made services – sign-in, payments and notifications don't have to be written from scratch.
- Prepare content and decisions early – "waiting for the texts" downtime costs money too.
- Check whether a PWA would do – sometimes an app in the browser solves the problem for a fraction of the price. You'll find a comparison in PWA or a mobile app.
How to get a reliable quote
A few sentences are enough: who the app is for, what problem it solves, what the 3–5 most important features are, whether you already have a visual design or a system it needs to connect to, plus a rough deadline and budget. Based on that we prepare a scope and a price range – free of charge. Read more about how we work on the mobile apps page.
Related services: mobile apps, web apps.