App development cost — a calculation instead of a price range

You have three quotes on your desk for the same application: roughly CHF 9,000, CHF 30,000 and CHF 105,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 for the Swiss market. 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: what we could and couldn't verify about an hourly rate, 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 Switzerland — and that's a completely different statement from saying there's no data about the IT sector at all.

We looked for a Swiss trade body publishing developer rate cards, and for Swiss labour-cost statistics comparable to what other countries publish. Eurostat's own Swiss labour-cost figure was last measured in 2016, and we don't use it. The one published Swiss reference point we found is a pricing study by Beyondweb, reviewing 161 Swiss agencies with prices from 36 of them, giving an hourly rate of CHF 120–250, average CHF 166 — but on only ten observations, and it prices websites and web-agency work, not custom application development. We cite it later, with that caveat attached, rather than pretend it answers a question it doesn't.

What's left otherwise is vendors' own price lists, and here you can see why you can't average them into anything. Reading a range of pages that quote application prices, you find the same shape again and again: 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 for which, as this section explains, there is no solid public source.

Step 1: no usable Swiss cost-per-hour figure

For most European markets you could derive a labour-cost figure from Eurostat and work forward from there. For Switzerland, Eurostat last measured this in 2016, and we're not building on a figure that old. The one number we do have is Beyondweb's CHF 120–250 hourly range for Swiss web agencies, average CHF 166 — useful as an order of magnitude for agency-billed work, but built on ten observations and pricing websites, not application development specifically. The same study also lists a "web platform" price of CHF 30,000–70,000, but on only two observations — far too few to treat as anything but a rough sense of scale, which is why we don't build on it either. Treat both figures as data points, not a benchmark to hold anyone to.

Step 2: our own rate, and why it sits below that range

Our own rate is CHF 110 per hour — our own assumption, not a measured market rate, because nobody has measured one for application development specifically. It sits below the CHF 120 floor of the Beyondweb agency range from Step 1 — we're stating that plainly rather than smoothing it over: Beyondweb's figure prices website and web-agency billing, on a small sample, not application development.

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

The one real spread we have is Beyondweb's own range: CHF 120–250 an hour, roughly double, on ten web agencies pricing websites, not applications. If you're looking at quotes that differ three- or tenfold, that gap doesn't live in the rate. It lives 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 Swiss aggregate for what businesses actually pay to have a web application built. It's the same kind of gap our own study of the Polish market addresses, but strictly for Poland; we don't extend its figures to Switzerland.

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 Swiss 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 CHF 25,000, a standard application at CHF 72,500, and an enterprise multi-module system at CHF 250,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 CHF 4,000 for an MVP, managed-cloud hosting is CHF 200 a month, an on-call support arrangement with an SLA is CHF 750 a month, and each integration with an external system is CHF 4,000. 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 CHF 25,000 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 CHF 4,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 CHF 40,000–70,000 one-off, plus CHF 1,000–2,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. 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. OVHcloud does not publish these prices in Swiss francs at all — this is the euro price as OVHcloud itself lists it, and we're not converting it into an invented CHF figure. A few euros to about twenty a month either way. 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.