Mobile app quote — why “from PLN 30k” means nothing and what to ask

“Mobile apps from PLN 30,000.” You see it on software house websites, in ads and in emails from sales reps. The number is specific, sounds credible and instantly becomes the reference point for the rest of the conversation. The trouble is that it tells you nothing about your project — yet it very effectively distorts your judgement of every offer you read afterwards.

This article isn't about how much an app costs (we've covered that separately in How much does a mobile app cost in 2026). It's about the quoting process: how to read an offer, what to ask before you sign a contract, and how to compare two proposals where one is three times the price of the other.

Why “from X thousand” is a marketing message, not a quote

1. It's a price anchor, not a forecast

Anchoring is the best-documented effect in negotiation psychology: the first number you hear shapes how you judge every number after it. If you start from “30k”, an offer of PLN 180,000 will sound like daylight robbery — even if it describes a scope six times larger and is the only honest proposal on the table.

Notice the construction: “from” commits to nothing. All it takes is for the company to have delivered one project at that price at some point — or for such a project to be theoretically possible to price.

2. Nobody knows what the word “app” covers

The same figure can hide wildly different things:

• an app for one platform or for both,
• with a ready-made backend on the client's side or with a backend and API to build from scratch,
• with a UI design or built on a template,
• with testing and release to the App Store and Google Play, or with a “the rest is up to you” package,
• with a warranty and maintenance, or with zero support after handover.

The difference between the extremes isn't a dozen or so per cent — it's a multiple.

3. The lowest price usually describes a project you don't have

“From” prices come from the simplest possible case: one platform, a handful of screens, no integrations, no login, no payments, no admin back office. A real business product almost always has login, an admin panel, notifications and at least one integration — and each of these is a separate line in the budget.

4. It hides what actually drives cost: non-functional requirements

Two apps with an identical list of screens can differ in cost by a factor of two because of things you can't see on a mockup: offline mode, data synchronisation across devices, security and compliance requirements, WCAG accessibility, performance with large datasets, support for older devices. These typically account for 20–40% of the budget and are the most common source of differences between offers.

What really makes up the cost

Before we get to the questions, it's worth establishing what you're actually looking at in an offer. The cost of an app is the product of four variables:

Technology — Flutter, React Native, Kotlin Multiplatform or native — affects cost far less than the debates around it would suggest. We break this down in Flutter vs React Native vs Kotlin Multiplatform. If a vendor explains a big price difference with “because we build in X”, that's usually not the real reason.

Anatomy of an honest quote

A good quote looks boring: it's a table, not a single number. It should include:

1. A breakdown into modules or features with a separate estimate for each. Without it you can't trim anything — and trimming scope is the only real budget lever.
2. A range, not a point. An estimate of “PLN 140,000” is less credible than “PLN 130,000–170,000”. A single figure for a project nobody has designed yet means someone has either added a large buffer or hasn't priced in the risk.
3. Explicit assumptions. What the vendor hasn't seen, what they assume is on your side, what they treat as provided (content, API access, developer accounts).
4. A list of exclusions. What is not included in the price — often more important than what is.
5. A breakdown into phases with milestones and a budget assigned to each.
6. Costs outside the project: developer accounts (Apple USD 99/year, Google a one-off USD 25), hosting, third-party services, licences.
7. A post-launch maintenance model — an indicative annual cost.

If you receive a PDF with one number and a paragraph of description, you don't have a quote. You have a sales pitch.

Twelve questions worth asking before you sign

This is the list we use ourselves — including when a client comes to us with a competitor's offer and asks us to assess it.

About scope

1. What exactly does this price cover — please break it down by feature. An answer of “the whole project” is a warning sign. You want to see line items: login, admin panel, push notifications, integration X.

2. What isn't included in this price? The single best question in the whole conversation. Typical omissions: backend, admin panel, graphic design, testing on physical devices, store release, copy, translations, data migration.

3. Is the backend in scope, or are you assuming I'll provide the API? A surprisingly common gap. If you don't have a ready API and the offer doesn't include one, the budget is usually short by 30–50%.

4. Who is responsible for releasing to the App Store and Google Play? Publishing isn't just “uploading a file”. It means developer accounts, a privacy policy, data collection forms, store descriptions, graphic assets and a real chance of rejection by the reviewer. Plan time and budget for it.

About ways of working

5. How did you estimate this project — what was it based on? You want to hear that someone broke the scope down into tasks and estimated them. An answer like “from experience, we've built similar things” means estimating by analogy — it can be accurate, but it can't be verified or trimmed.

6. What happens when the scope changes? It will change, guaranteed. Ask about the specific process: who prices the change, how quickly, whether there's a buffer in the budget, how the change affects the deadline.

7. Who will actually write the code, and what experience do they have? The offer shows seniors; the project sometimes gets interns. Ask for the team line-up with roles and time commitment. Ask directly whether any work is subcontracted.

8. How often will I see a working version? The answer should be: every two weeks, on your own phone. Not screenshots, not a demo at the end of the project.

About what happens after launch

9. Who owns the code and where is the repository? The contract must transfer the economic copyright to you, and the repository should be accessible from day one — ideally in your own organisation on GitHub or GitLab. No access to the code during the project is a serious risk.

10. What does the warranty cover and how long does it last? Distinguish bug fixing (should be free, typically for 3–12 months) from further development (paid). Agree what counts as a bug and what counts as a new feature.

11. How much does a year of maintenance cost? An app is an ongoing commitment: iOS and Android updates, changing store requirements, libraries, fixes. Realistically 15–20% of the project budget per year. An offer that says nothing about this is hiding part of the cost.

12. What happens if we want to switch vendors? An awkward question — and valuable for exactly that reason. A good partner will talk about documentation, coding standards and a handover process. A bad answer is usually the start of vendor lock-in.

Red flags in offers

• A same-day quote with no questions asked. A reliable estimate requires understanding the scope. If nobody asked you anything, they priced an idea, not your project.
• A price well below the market. It usually means omitted scope that will come back as change requests — often costing more than the offer that was higher at the outset.
• No breakdown into phases. A “50% upfront, 50% at the end” payment on a project lasting several months shifts all the risk onto you.
• A deadline with no margin. “Three months” without specifying what depends on your decisions and deliverables is a deadline that won't survive contact with reality.
• Reluctance to show the code or repository.
• “We'll do it with AI, so it'll be cheaper.” AI tools genuinely speed up the work, but the code still has to be read, tested and maintained. We describe what we find in such projects in AI-written code in production.
• No questions about non-functional requirements. Nobody asked about offline, security, number of users or integrations? These topics will come back — with an invoice.

How to compare two offers where one costs three times more

This is the most common situation: PLN 60,000 and PLN 190,000 for “the same thing”. It's almost never about the margin.

Step 1. Reduce both to a common feature list. Build a spreadsheet: rows are features, columns are offers. Usually within half an hour it becomes clear that the cheaper offer doesn't include the backend, the admin panel or the second platform.

Step 2. Check who asked more questions. The number and quality of questions before quoting is the best available indicator of how thoroughly the scope was priced.

Step 3. Calculate the total cost over two years. Add maintenance, fixes, hosting and third-party services. A cheaper offer with lower code quality can overtake the more expensive one in year two.

Step 4. Ask both vendors the same technical question. For example: “how will you handle data synchronisation when the user has been working offline for two hours?”. The answers separate vendors very quickly.

Step 5. Ask for references from a project of similar complexity — and pick up the phone. Don't ask whether it went well; ask what went wrong and how the vendor dealt with it.

If the decision is a big one and you have no one technical on your team, consider an independent assessment of the offer. An audit and consultation before signing the contract costs a fraction of the project and is usually the best-spent hour of the whole undertaking.

How to get a meaningful quote in the first place

The quality of a quote depends on the quality of the brief. Before you send an enquiry, prepare:

• The problem and the user — one sentence: who will use the app and why.
• A list of the main journeys — 3–7 things the user needs to be able to do.
• Platforms — iOS, Android, both? There's a chance a web app or PWA will do.
• The state of your back end — do you have a backend, API, database, admin panel? Anything already working?
• Integrations — which systems the app has to connect to, and whether they have API documentation.
• Non-functional requirements — offline, GDPR, accessibility, expected number of users.
• Budget and deadline — a realistic range. Sharing your budget doesn't mean you'll “pay the maximum”; it means you'll get a scope proposal that fits those limits, instead of an offer that misses in both directions.

You don't need a specification or mockups. You need clarity about the problem — a good vendor will help you pin down the rest, and if they don't, that tells you something too.

Summary

“From 30k” says nothing about your project — it says something about the sales strategy of the company that published it. What's valuable is a quote broken down by feature, with its assumptions, exclusions, phases and maintenance cost spelled out.

Three things worth remembering:

1. Always ask what isn't included in the price. That single question reveals more than the rest of the conversation put together.
2. Compare scopes, not numbers. A 3× difference almost always lies in the backend, the second platform or the non-functional requirements.
3. Count the two-year cost, not the build price. Maintenance realistically comes to 15–20% of the budget per year and it's unavoidable.

At Mobilesoft we quote with a breakdown into phases and features — together with a list of what we're deliberately leaving out of the first version. See how we approach building mobile apps, check out our case studies or go straight to getting a quote for your project. If you'd like to understand market price ranges first, start with How much does a mobile app cost in 2026 and How much does a mobile app MVP cost. And if you have an offer on your desk that you can't assess — get in touch and we'll go through it together.