App development cost — a calculation instead of a price range

You have three quotes on your desk for the same application: PLN 18,000, PLN 60,000 and PLN 210,000. All from firms that look credible. The first instinct is to search for what an application "should" cost — and that's where the trouble starts, because the answer you're looking for doesn't exist. Not because nobody has calculated it, but because no public benchmark for the price of custom software development exists in Poland. Everything you'll find is a seller's price list.

This article won't add another range to that pile. Instead, it shows a calculation you can rebuild yourself: where an hourly rate comes from, why two quotes for the same thing can differ threefold, what an application really costs after launch, and what a quote has to contain before you can compare it to anything. Every figure we give has a source and a date attached. Where there's no source, we describe the mechanism instead of a number.

Why won't anyone give you a price for an application?

Because there's nothing to give. No institution or industry body publishes prices for custom software development in Poland — and that's a completely different statement from saying there's no data about the IT sector at all.

GUS (Statistics Poland, Główny Urząd Statystyczny) publishes wages. In its monthly socio-economic information you will find the average gross monthly wage in the "Information and communication" section — in July 2026 it was PLN 15,334.67, against PLN 9,509.02 across the whole enterprise sector (GUS, published 25 August 2026). That's data about what people earn, not about what a project costs. Software development prices simply aren't the subject of any official statistical publication.

Industry bodies don't publish them either. The Software Development Association Poland (SoDA) has four items in its reports tab — three editions of the "IT Industry Sentiment Barometer" (Barometr Nastrojów Branży IT) and a study on company sales (checked on 22 September 2026). None of them is a price list or a rate card.

What's left is vendors' own price lists, and here you can see why you can't average them into anything. Two Polish sites publish prices today for the same label. aplikacje-mobilne.biz prices a "basic" app at PLN 4,000–19,000. itcraftapps.com prices a "simple" app at PLN 30,000–100,000. The lower bound of one price list and the lower bound of the other differ 7.5 times. Neither gives a measurement date, a sample or what exactly fits into the word "simple".

It is also worth seeing what these price lists have in common. Reading a dozen Polish pages with app prices, you find the same construction everywhere: three tiers named "simple", "medium" and "complex", a list of price-driving factors underneath, and the current year in the title. The year signals that the text is current, not the date of a measurement — underneath there's no observation count, no collection period and no definition of the categories. Small wonder: these pages are sales material and have no duty to be a study.

That's not one seller being dishonest. It's evidence that the phrase "simple application" doesn't mean anything precise enough to price. Until you know how many screens, how many user roles, how many integrations and whose time is included, two very different numbers can both be "true" — they're describing two different products under one label.

The practical conclusion for a buyer isn't philosophical: stop looking for a market price, start comparing scopes. The rest of this article shows you how.

What the price actually consists of

An application's price is the product of three things: a rate, time and scope. Scope describes your requirements, time follows from scope, and the rate is the one number you can actually derive from public data. Let's do that.

Step 1: what a month of one person's work costs

The largest job board with mandatory salary ranges publishes the medians of those ranges once a year. In "IT job market in Poland 2025/2026" (Rynek pracy IT w Polsce 2025/2026, No Fluff Jobs) — the eighth edition, based on job ads published between 1 January and 31 December 2025 — a senior fullstack developer on a B2B contract has a median lower bound of PLN 23,520 and upper bound of PLN 28,560 net a month, plus VAT. Backend: 22,680–28,000. Frontend: 20,160–26,840. Mobile: 21,840–26,880. DevOps: 25,000–30,000. Testing: 20,160–25,000.

Two caveats that the No Fluff Jobs report gives itself. First, these are amounts from job ads, that is the employer's declaration, not signed contracts — the authors checked this separately and report that 71% of people received pay within the advertised range and 11% higher. Second, these are medians of ranges, not median earnings.

An independent measurement by a different method gives the same order of magnitude. Bulldogjob doesn't read job ads but asks working people: in a survey run from 15 January to 16 February 2025, with 4,331 responses after quality checks, the median B2B contract across IT was PLN 20,800, and for seniors PLN 24,000.

Step 2: converting to an hour

Take a working month of 168 hours, that is 21 days of 8 hours. That's an assumption, not a fact — you can swap it and recalculate everything. On that assumption PLN 23,520 gives about PLN 140 an hour, and PLN 28,560 about PLN 170. This is the rate for the developer alone, with 100% of hours billed to the client.

Step 3: why a firm's quote is higher

Nobody bills 100% of their time. Recruitment, holidays, sick leave, sales meetings, downtime between projects, internal code review — all of that is paid time that isn't sold. Assume 70% billability — this is our own assumption for this calculation, not market data, and it's worth asking any supplier for their own figure. At that billability the same PLN 140–170 becomes PLN 200–243 per hour of own cost. And that is still before adding a project manager, a tester, infrastructure administration or any margin.

That is where the rates you see in quotes come from. It isn't margin, it's arithmetic. Our own rate is PLN 220 an hour for the Polish market — we give it as our assumption, within the range above, not as a market rate, because nobody has measured one.

Step 4: why two quotes for the same thing can differ threefold

Notice what came out of this calculation: the rate varies roughly twofold, from 140 to just under PLN 300 an hour. So if you get quotes that differ three- or tenfold, the difference isn't in the rate. It's in the number of hours, in other words, in scope.

The one question worth asking every supplier in the same sentence: how many hours are you assuming, and for what. A quote that can't answer isn't cheaper — it's undefined.

What it costs in practice

Since there's no public benchmark, we made our own. Our report on web application costs is based on 118 price observations from 92 entities, collected from March to May 2026. The sample has 58 software houses, 10 interactive agencies, 14 publishers of price benchmarks, 7 publishers of SaaS price lists and 2 freelancers.

Two numbers from this report have a sample large enough to mean something:

The other categories in the report have between two and seven observations, and we deliberately don't quote them here — a median of three numbers isn't a median, it's the middle one of three.

We give the number of observations next to every median not out of pedantry, but because without it a median can't be checked. A good example is one the report flags itself: the "full application" category comes out lower than the "medium complexity" category, which is arithmetically possible only if the two names mean different things in price lists. It's the same disease as in the paragraph about the "simple application" — the labels have no common definition, so comparing them is at your own risk.

How to use this? A median MVP of PLN 30,000 says that if your requirements fit into one user path and you get a quote for PLN 8,000, you are probably buying something other than you think. And if you get PLN 150,000 — either your project isn't an MVP, or you are talking to someone who is pricing a different scope. In both cases the answer is "ask about scope", not "negotiate the price".

Our own prices, and what stands behind them

Now the part where we need to be very precise, so it doesn't sound like we're contradicting ourselves. A median of PLN 30,000 for an MVP is the market, measured on other people's price lists. Our price line looks like this: a lean MVP from PLN 10,000, an MVP from PLN 30,000 — and the final amount always comes from an individual quote. A standard application starts with us from PLN 145,000, and an enterprise system from PLN 500,000. The calculator shows these prices.

That our "from PLN 30,000" coincides with the market median doesn't mean that we count the same thing as the price lists. The market median is a headline number from a price list — the amount from which the conversation starts. With us, the items usually left out of price lists are separate, visible lines: a discovery phase with research and wireframes adds PLN 8,000 for an MVP, managed-cloud hosting is PLN 400 a month, an on-call support arrangement with an SLA is PLN 1,500 a month, and each integration with an external system is PLN 8,000. The calculator shows the result as a ±15% range, because that's the honest uncertainty at brief stage.

So it isn't that you pay us for "more features" than a quote taken from a price list — it's that the rest of the bill is itemised up front with us, rather than added later.

To be clear: we aren't claiming our price is the market price, or that a market price is what you'd pay us. These are two different things, measured two different ways, and both appear in this article so you can tell them apart in any quote you receive.

What really drives up the cost, and what doesn't

Having priced dozens of projects, we see the budget slip in the same places every time — and almost never where the client expects.

Integrations with someone else's systems. Every connection to an external system — payments, an ERP, a courier, an accounting platform — is separate work: authentication, data mapping, handling the other side's errors, and testing against an environment you don't control. In our calculator that's PLN 8,000 per integration, and it's the line item most likely to multiply as a project progresses.

Roles and permissions. "Admin sees everything, user sees their own" is one rule. Five roles with partially overlapping permissions is a matrix that has to be designed, implemented and tested in every combination. That's usually the difference between an application and a system.

Data migration. Data from a previous system is never clean. Duplicates, gaps, three different date formats and fields used for something other than their name is work you can't see in a demo and can't price without opening the database.

Compliance and audits. Formal requirements can outweigh the cost of the application itself. In our configuration, compliance levels such as SOC 2, ISO 27001, HIPAA or PCI-DSS run PLN 80,000–140,000 one-off, plus PLN 2,000–4,000 a month. If your industry requires one of these, it's the first line item to settle, not the last.

Tempo. According to our calculator, cutting the timeline by 30% raises the price by 40%, and by half doubles it. Not because anyone's exploiting your urgency, but because a larger team working in parallel needs more coordination per unit of output.

Your own time. The line item counted least often, because it never appears on any invoice. The brief, workshops, sign-offs, acceptance testing, decisions the team is waiting on — that's hours from someone at your company. A project where nobody on your side has time to decide costs more regardless of the supplier's rate, because delays are billable too.

And now, contrary to popular belief, what isn't the main driver of cost. Choice of technology — provided you stay within commonly used solutions — moves the budget within a few percent; in our experience, rates for specialists in popular stacks don't differ much, as you can see in the No Fluff Jobs tables. A "nicer" interface doesn't move it much either: design work scales with the number of distinct screens and states, not with how polished any one of them is. If one offer differs from the rest by 200% and explains that with technology or design quality, that isn't an explanation of a scope difference.

What an application costs after launch

This is the question that most often gets answered as a percentage: "upkeep is 15–20% of the project's value a year", or "assume 20%" — a figure that circulates on agency blogs. We looked for a primary source for that rule and didn't find one. What you find instead are blogs quoting other blogs, with a spread from 10% to 30%, without a sample, a methodology or a measurement period behind any of them. So this article gives you no percentage for upkeep.

Instead: a calculation from line items. Start with the one that's easiest to verify.

The server is the cheapest line in this calculation. On OVHcloud's price list, a virtual machine with 2 cores, 4 GB of memory and 40 GB of NVMe storage costs PLN 16.32 net a month, and a stronger one — 8 cores, 24 GB, 200 GB — costs PLN 85.08 net, both with a daily backup and volumetric-attack protection included as standard. Twenty-odd to a hundred złoty a month. If someone explains a maintenance fee by pointing to server cost, you've just seen what that server actually costs.

Store fees are fixed and public. The Apple Developer Program is 99 USD a year, shown in local currency only at registration, so we don't convert it. A Google Play developer account is a one-time 25 USD fee — once, not yearly.

Everything else is somebody's time. Here it helps to use the categories from ISO/IEC/IEEE 14764 — published 21 January 2022, describing software maintenance as an iterative process, with planning starting during development itself. It splits maintenance into four kinds: corrective (fixing bugs found after launch), adaptive (adjusting to changes around the application — a new OS version, a changed payment-provider API, a new regulation), perfective (improving performance and maintainability) and preventive (removing problems before they surface). The standard describes a process, not a price list — which is exactly why no percentage follows from it.

The practical calculation, then, is: hosting plus domain, backups at a defined frequency, uptime and performance monitoring, dependency updates on a set cadence, an agreed incident-response time, and a separate budget for changes forced from outside. Our own maintenance model prices exactly this way — a monthly amount for each of these line items, with no reference to project value at all. A service agreement that quotes one figure and the word "care" isn't telling you what you're paying for.

How to read a quote you've received

Since the difference between offers lives in scope, only quotes that describe scope are actually comparable. A good quote has four parts, and their absence tells you you've received a price list instead of an offer.

The last row matters most, because that's where most conflicts live. A fixed-price arrangement gives you a known budget up front and less risk of surprises, but any scope change needs a formal change order — and the more rigid the contract, the bigger the buffer a supplier will price into it. Time-and-materials billing means you pay for hours actually worked and can change direction mid-project, but you're the one watching that scope doesn't quietly grow without limit. A common compromise is a fixed price for a defined core, with hours for everything beyond it.

Questions worth putting to every bidder, word for word:

• How many hours are you assuming, and how are they spread across phases?
• What exactly is outside this price?
• Are testing and bug fixes included, or billed separately?
• Who owns the source code, and where will it be kept?
• What's the response time after launch if something breaks, and what does that cost?

And a word about offers noticeably cheaper than the rest. Cheaper doesn't automatically mean worse — it means the same arithmetic from the rate section applies on the supplier's side too. If a price is an order of magnitude lower than everyone else's, either the scope is different, or testing, documentation and support aren't in it, or someone has under-costed the project and the gap will surface later — the worst outcome, because you'll both end up fixing it.

Where to start

Start with the smallest version that solves one real problem — an MVP. Not because it's cheaper by some fixed percentage (nobody has measured that), but because it's the only way to find out what you actually need before you pay for the full version. A scope you can't describe is the most expensive thing in this whole calculation.

In practice: write out the user journey step by step, mark where the application has to talk to another system, count the roles, and note which data needs migrating from what you have today. With that document, you can go shopping for quotes that can actually be compared.

Back to the three quotes from the start. With that document in hand, ask all three suppliers the same question about hours and exclusions, and compare the answers, not the totals. Nine times out of ten, the gap sits in three or four specific line items — integrations, roles, migration, post-launch support — and once those are aligned, the offers converge enough that the decision stops being a lottery.

If you want to see the order of magnitude first, the web application cost calculator shows a result along with the line items behind it. Along the way, it's worth reading what the process looks like on the supplier's side and what to prepare before you start. If you're considering a mobile app, we cover that family of costs separately in our article on building mobile apps. And if you'd rather talk through a specific scope, we build systems to order.