There is no single price for every product. This guide shows practical ranges, the decisions that move them, and an estimator that makes its assumptions visible.
Before the number
Screen count says very little. The main user journey, data, access rules, integrations, release platforms, and clarity of the starting point matter much more.
These ranges cover projects I can take on directly when the scope is clear. They apply to clients in Italy or worldwide; the final quote depends on what already exists and the first release being delivered. VAT, where applicable, and third-party costs are excluded.
Orientation ranges
They are not fixed packages. They help establish the likely order of magnitude before a quote.
One defined outcome: payments, a private area, an API, an internal panel, or a flow to finish.
Assumption: The project runs, access is available, and the work stays within one clear area.A usable web application with one main journey, the required backend, and deployment.
Assumption: One primary user type, few integrations, and secondary features left for later.A first iOS and Android app with a backend, device testing, and a distributable build.
Assumption: The mobile flow is defined and does not also require a full web app and extensive back office.The same journey works across web, iOS, and Android with shared backend and product logic.
Assumption: It should be phased: prove the core value first, then add the remaining surfaces.Estimator
Choose the starting point and only the capabilities needed in the first release.
Why the range moves
These are the areas I check before turning an orientation range into a quote.
Who uses the product, what they must complete, and which state needs to persist.
A working repository is different from code without tests, deployment, or available access.
Permissions, account recovery, failures, and intermediate states are part of the real product.
Payments, maps, email, and APIs add limits, test environments, and failure behaviour.
Adding iOS and Android means device testing, builds, store materials, and review.
Logs, analytics, cloud costs, errors, and updates matter when people actually use the product.
What the number means
The final quote states what I will deliver, what I need from you, and what remains outside the scope.
The proof behind the estimate
Mappu is a product I built and maintain directly. It combines web, iOS, Android, backend services, AI, maps, audio, accounts, and payments—the same elements that move an estimate.
Accounts and data need to remain consistent across web and mobile.
Generation feeds itineraries, maps, and audio rather than living in an isolated demo.
Stores, analytics, errors, and usage-based services remain after the first deployment.
Frequently asked questions
Yes, if the first outcome is smaller: one journey, one platform, fewer roles, and no unnecessary integrations. A static prototype can cost less, but it is not the same as a usable product.
They often include different work. Design, backend, admin tooling, testing, release, account handover, and support after launch must be explicit before prices can be compared properly.
No. It produces a range consistent with the choices entered. Before quoting, I review the starting point, responsibilities, edge cases, and exact delivery criteria.
It can reduce the work or add unknowns. I first check setup, the relevant code, tests, access, and the deployment path. A defined feature can only be quoted after that review.
No. The main journey should work from start to finish. Secondary features are postponed, not reliability, data ownership, or the ability to use the result properly.
Not unless the quote says so. Cloud, email, maps, AI models, developer accounts, and other services have their own costs. I make them visible because they continue after delivery.
Next step
Send me the estimator summary and whatever already exists. I will tell you which assumptions need checking before we discuss a quote.