Powstania Warszawskiego 15
31-539 Kraków
Pick what your app has to do and the calculator returns the range we would quote, the timeline that goes with it, and the specific choices that moved the number. The questions are about how the product works rather than what industry it sits in, because that is what the price actually follows.
Everything needed to get a working product into both stores: product scoping, UX and UI design, development on one shared codebase, QA on real devices, App Store and Google Play release, and handover documentation. It does not include your own running costs, paid third party services, or work added after the scope is signed.
Scoping and product brief, design, development, QA, store release, build pipeline, handover documentation, and the acceptance protocol that closes delivery.
Store developer accounts, hosting, paid third party services, content and translations, marketing, and anything added after the scope list is signed.
A single figure. Any honest range on a first conversation is a range, and it narrows once the scope is written rather than once someone feels more confident.
Four things dominate, and none of them is your industry: payments, offline behaviour, integrations with systems you already run, and the number of user roles with different permissions. Screen count barely matters. Two apps that look identical can differ several times over in price because of what happens behind those screens.
Money brings store rules, edge cases and a review conversation. Marketplace payouts are the heaviest version, because money moves between two parties and every failure state has to be handled.
Reading offline is modest. Writing offline creates a second source of truth and everything that comes with reconciling it later. The first question is always which of the two you actually mean.
Every external system is a party who can change an API without asking you. The cost is rarely the connection itself, it is the error handling and the version you have to keep supporting.
User roles are the quiet one. Two roles is a feature. Five roles with different permissions is an architecture, and it shows up in design, in the backend and in testing, three times over.
A calculator narrows a range. A scope list sets a price. We move from one to the other in a scoping conversation that produces a written product brief, a list of what is included and, more importantly, a list of what is excluded.
Fixed price is only honest when that list exists. On a vague scope, a fixed price means either you pay for our risk buffer or we quietly narrow what gets built, and both sides lose.
Current package shapes are on the pricing page. If you want the reasoning behind the ranges rather than a tool, we break it down in our guides to mobile app development cost and MVP cost by app type.
Because price follows structure, not sector. A booking product for a clinic and one for a garage cost the same when they have the same roles, payments and integrations. What changes the number is how many outside systems the app has to be correct about and how many kinds of user it serves.
It puts you in the right band, which is what a first conversation needs. It cannot know the one rule inside your operation that changes the architecture, and that rule exists more often than not. Treat the output as a range to sanity check other quotes against, not as a price.
Below a certain point a project cannot include design, QA and a proper store release, and skipping any of those creates a bill later rather than a saving now. We would rather tell you the floor than quote under it and cut the parts you cannot see.
No. Both platforms come from one shared codebase, so the second one adds testing and store work rather than a second build. Choosing a single platform saves less than people expect, which is why the calculator only takes a modest amount off.
Your running costs. Store developer accounts, hosting, and paid third party services are yours and continue after launch. We break those down in the guide to app maintenance cost.
Usually yes, by cutting version one rather than by cutting quality. Everything removed is written down as excluded so it returns later as a decision. That is a real saving. Removing QA or design is a deferred cost pretending to be one.
Eight to twelve weeks from approved scope for a defined first version, longer for operational systems with integrations. The calculator shows the range that matches your selections, and the full picture is on our page about how long it takes to build an app.
Tell me what you selected and what the app has to do. I will tell you which parts drive the price, what could come out of version one, and what a scoped estimate would look like.
Get a scoped estimate