App development cost — a calculation instead of a price range

You have three quotes on your desk for the same application: roughly €12,000, €39,000 and €137,000 — illustrative round numbers. 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 at European scale. 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 Europe — and that's a completely different statement from saying there's no data about the IT sector at all.

Eurostat publishes labour costs. In its statistics for the information and communication sector across the EU27, the average hourly labour cost an employer bears — wages plus employer contributions — was €48.20 in 2025 (Eurostat, lc_lci_lev, read 29 September 2026). That's data about what an hour of work costs an employer across the whole sector, 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. We looked for a European trade association publishing developer rate cards, and found none. What we found instead were agency and freelance-platform price lists, none built from a stated methodology or sample.

What's left is vendors' own price lists, and here you can see why you can't average them into anything. Price pages of software houses tend to share the same shape: three tiers, usually labelled "simple", "medium" and "complex", a list of price-driving factors underneath, and the current year in the title. The year signals that the page is current, not that anything was measured on a given date — underneath there's usually no observation count, no collection period and no definition of what "simple" actually includes.

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 an hour of work costs an employer

Eurostat's labour-cost statistics give a direct answer for the sector: €48.20 per hour worked, EU27, information and communication sector, 2025 figures. Unlike a job-board salary range, this already is a cost-per-hour figure — there's no monthly salary to divide by working hours, because it's reported that way from the start.

One caveat worth carrying with the number: this is a whole-sector average, across every role from junior support staff to senior specialists, not a figure specific to software developers the way a developer-salary survey would be. It tells you the order of magnitude of what an hour of work costs an employer in this sector — not what a senior developer's time specifically costs.

Step 2: from labour cost to billable-hour cost

Nobody bills a client for 100% of the hours they're paid for. 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, €48.20 becomes about €69 per billable hour of cost. That's still before adding a project manager, a tester, infrastructure administration or any margin.

Step 3: our own rate, and the gap between it and Step 2

Our own rate is €143 per hour — our own assumption, drawn from our own price configuration, not a measured market rate. It sits well above the ≈€69 sector-average cost basis from Step 2. What accounts for that gap is exactly what Step 2 already named — project management, testing, infrastructure, non-billable time, sales, margin — but we found no public source that quantifies how much of it each of those takes, so we say that plainly rather than argue the gap away.

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

A quote is a rate multiplied by hours. The rate is one number, and it's easy to ask every supplier for it and compare directly. If the totals on your desk differ three- or tenfold and the rates you're quoted don't, 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.

There's no European aggregate for what businesses actually pay to have a web application built. Our own study of the Polish market fills that gap for Poland only, and we don't extend its figures to any other country.

Our own prices, and what stands behind them

Now the part where we need to be precise, so it doesn't sound like we're contradicting ourselves. There's no European median we're comparing ourselves against — what follows is simply our own starting prices and what's itemised separately alongside them.

In our calculator, an MVP starts at €32,500, a standard application at €94,250, and an enterprise multi-module system at €325,000. Those are our own prices, set in our configuration — not a statement about the market.

What makes that starting price different from a typical headline quote is what's already a visible line item rather than something added later: a discovery phase with research and wireframes adds €5,200 for an MVP, managed-cloud hosting is €260 a month, an on-call support arrangement with an SLA is €975 a month, and each integration with an external system is €5,200. The calculator shows the result as a ±15% range, because that's the honest uncertainty at brief stage.

Our MVP base deliberately covers only the core user journey — no admin panel, no advanced settings. A design system is disabled for it outright, as overkill. So it isn't that we're offering "more features" for €32,500 than a lower quote elsewhere — 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 €5,200 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 €52,000–91,000 one-off, plus €1,300–2,600 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. 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 €3.81 net a month, and a stronger one — 8 cores, 24 GB, 200 GB — costs €19.96 net, both with a daily backup and volumetric-attack protection included as standard. A few euros to about twenty 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.