Web application — what it is, its types and when you need one

A website informs. An application calculates, saves and remembers

A website answers the question "who are you and what do you do". A web application answers the question "what's happening with my order" — and to answer that, it has to save something, calculate something and remember it for your next visit. That isn't a difference of size or budget. The difference is whether anything is left behind on the other side.

There's no Eurostat-style aggregate to show the scale of that gap for Switzerland — the EU's survey of ICT usage in enterprises covers member states only, and Switzerland isn't one of them. What we can say without a number: having a website and being able to actually transact on it are two different capabilities, worth checking separately rather than assuming one implies the other.

This article is about that gap: what a web application actually is, what types it comes in, what it costs, and how to tell that your company has reached the point where a website stops being enough. The examples are our own — we describe applications we built for ourselves, which you can open while you read.

What a web application is

A web application is a program that runs in the browser, and the data it works on lives on a server, not on your computer. You open the address, log in and work on the same set of data as the rest of the team — without installing anything and without emailing files back and forth.

Mechanically, the difference from an ordinary website comes down to what the server does with the request. MDN's documentation describes a static site as one that "returns the same hard-coded content from the server whenever a particular resource is requested". A dynamic site, on the other hand, is one where "some of the response content is generated dynamically, only when needed", with HTML pages built by "inserting data from the database into placeholders in the HTML templates". A web application is the extreme case of the second kind: almost nothing in it is prepared in advance, because the content depends on who is logged in and what they did before.

The shorter "web app" means exactly the same thing. In English the two terms are used interchangeably, and no technical difference hides behind the shorter form.

From that one decision — the program runs in the browser, the data sits on the server — four features follow that, in practice, decide the choice:

• You install nothing. A new hire gets a link and a password, not an installer file and a visit from IT.
• One version for every platform. Windows, macOS, Android, iOS — the same application, because a browser exists on all of them. You don't maintain three separate builds.
• Data lives server-side. A backup happens in one place, and a laptop failure doesn't wipe anyone's work.
• Updates happen without the user doing anything. A fix goes onto the server and, from that moment, everyone works on the new version — nobody clicks "update" and gets left on the old one.

That last point has a flip side worth knowing up front: because everyone works on one version, a single deployment mistake affects everyone at once. That's why backups and the ability to roll back a change quickly matter for applications in a way nobody asks about for a brochure site.

Web application vs website — four concrete differences

The question "web application or website" is easiest to settle not through definitions, but through four questions about what happens to the data.

What it stores. On a website, content is created once, in the editorial process, and is the same for every visitor. In an application, content is created as it's used: it's the order someone placed yesterday, the support ticket from an hour ago, a calculation someone saved and wants to come back to. As long as nothing is created on the user's side, you don't need an application.

Who logs in. Logging in is the simplest test. If everyone sees the same thing, a website is enough. If one customer needs to see their orders and another customer needs to see theirs, you need accounts, permissions and a way to reset a password — and that's already an application, however modest it looks.

What's left after the tab closes. A contact form sends an email and its job is done. An application saves a state you can come back to: an interrupted application form, a shopping basket, a draft, a history. The moment someone says "we'd like the customer to be able to finish this later", the conversation is already about an application.

Who pays for upkeep. This is the difference almost nobody warns you about up front. A website means hosting, a domain and updates. An application means all of that plus a database, backups that are actually tested by restoring them, monitoring, and a budget for ongoing development — because an application that doesn't change for a year stops matching a process that has changed. Plan for upkeep from day one, not after launch.

The line is often blurry, and that's fine. A website with a form, a basket or a booking panel already has a piece of an application in it, and a large internal application usually has a few purely informational pages. It's not worth arguing about the name — it's worth counting how many of these four rows apply to your case. One is usually a website with an add-on. Three or four is a project you need to plan, maintain and budget like an application, whatever you call it in the RFP.

Types of web applications

Web applications are most often split by technology. For a company deciding whether it needs one at all, a more useful split is by role — who uses it and whose problem it solves.

An internal tool. Used by the team, not customers. A job register, a production dashboard, an equipment log, a duty rota. It usually replaces a spreadsheet that outgrew what it could handle, and it pays for itself fastest, because the number of users is known and the process already exists — it just needs to move somewhere two people can't overwrite the same row.

A customer portal. The customer logs in and sees their own data: orders, delivery status, invoices, documents, support tickets. This is the kind of application that takes the most load off the phone and inbox, because it moves the questions people ask several times a day onto the site itself. We don't have a Swiss aggregate to say how common this is.

A sales application. A configurator, a quote calculator, a booking slot picker, an order built to a customer's own specification. It works before the sale, not after: it should produce an enquiry that's already priced and described. This is usually the easiest shelf on which to stand out.

A subscription product. An application that is itself the thing being sold: customers pay for access. That's a completely different project from the three above, because upkeep, support and development become part of the business model rather than a backend cost. Before you go down this road, it's worth reading about the difference between off-the-shelf software and a solution built to order.

Standing apart from all of these is the PWA — the progressive web app. MDN defines it as "an application built using web platform technologies, but that provides a user experience like that of a platform-specific app", adding that "like a webpage, a PWA can run on multiple platforms and devices from a single codebase", while at the same time, "like a native application, it can be installed on the device, can operate while offline and in the background, and can integrate with the device and with other installed applications." It isn't a separate type of application in the business sense — it's a way of delivering one: the same web application, with an icon on the home screen. We cover when that's enough instead of a mobile app in mobile app or web app.

Web application — examples we built ourselves

The easiest way to show the difference is with applications you can open while you're reading. All of the following run on this site, and all of them exist because something couldn't be handled with content alone.

Cost calculators. Problem: "how much does this cost" comes up before the first conversation, and "it depends" helps nobody. The application: you pick a scope, the result recalculates on every field change, some questions appear only once an earlier answer makes them relevant, and the result can be saved and emailed with an itemised PDF estimate. We have eight such configurations, six of which have their own page — including the web application cost calculator. A website would give a price range, nothing more.

Quizzes. Problem: the reader doesn't know whether they need a website, a web application or a mobile app, and a checklist in an article makes them apply it to their own case. The application: every answer adds points to several categories at once, and the end result shows not just the winning recommendation but a ranking of the rest and which answer tipped it. We have four such quizzes; closest to this topic is the website, web app or mobile app quiz. A website doesn't know the reader's answers, so it can't add them up.

Brief wizard. Problem: the first project conversation takes two hours and still misses things, with the client answering questions they don't yet understand. The application: it walks through each step, shows questions that depend on earlier answers, can pre-fill fields from an industry preset, calculates an estimated timeline live, and saves the session automatically so you can leave and return with the same link. It exports to PDF, and the address given becomes one contact record in our CRM. You'll find it at project brief. A form sends an email and stops there — here, a state remains that both sides come back to.

Our own CRM with mailbox sync. Problem: a contact from a form, a calculator, a quiz and a phone call are four separate places, usually one person. The application: each channel saves into one contact record recognised by email address; the company mailbox (Gmail or Microsoft 365) adds correspondence metadata — subject, date, direction, never the message body; the domain links the contact to a company unless it's a personal address. It's internal, so it has no public page; what a smaller company actually needs from one is covered in CRM for small business. A website has nowhere to keep a relationship's history.

Meeting booking module. Problem: arranging a time by email averages four messages and one time-zone mistake. The application calculates free slots from the availability schedule and from Google Calendar, creates an event with a call link on booking, sends a confirmation with an .ics file plus cancel and reschedule links, then sends reminders a day and an hour before the meeting. More on what this looks like for a client: online booking system. A website would show you a phone number.

The common thread across all five: in each one, something is left server-side — a result, a set of answers, a session, a contact, a booked slot. That's the whole definition of a web application, just told five times.

When you need an application, and when a website is enough

Not every workflow problem is a problem that an application solves. Below are four signals worth watching for — and one condition where it's better to wait.

Data keeps coming back. The same piece of information circulates over and over: a customer gives it in a form, someone copies it into a spreadsheet, then into an invoice, then into a confirmation email. Every re-entry is a chance to make a mistake and a few minutes of someone's time. An application saves the data once and shows it in each of those places.

Someone logs in. If the conversation starts with "we'd like the customer to see their own…", that's already an application. A website has no way of recognising who's looking at it.

Numbers need calculating. A quote that depends on five parameters, a schedule that shifts when one date moves, a commission calculated from three components. As long as a person does that in a spreadsheet, the result depends on which person and which spreadsheet.

A process has stages. A submission moves through intake, quoting, approval, delivery and handover, and at each stage someone else needs to know it's their turn. You can run stages by email right up until one gets lost — and then nobody knows where things stand.

There's one condition where it's worth waiting: the process doesn't exist yet. If a company hasn't agreed how something should work, an application won't create that agreement — it will just lock in whatever variant happened to be built, and cost you for every change of mind afterwards. Sort the process out on paper or in a spreadsheet first, then code it. A well-run spreadsheet is the best possible preparation for an application.

We don't have a Swiss aggregate for how many businesses run CRM, ERP or their own digital sales channel — the EU's ICT-usage survey that would answer this doesn't cover Switzerland, and we haven't found a comparable published measure for the Swiss market. Check where you stand against a competitor or two before assuming a digital sales channel is already standard in your sector — without a number, that's a fact worth verifying directly rather than guessing.

What a web application costs, in brief

The full breakdown of cost is in a separate article: how much a web application costs. Here, just enough to know the order of magnitude.

There is no Swiss benchmark for web application prices that we'd put our name behind. The one Swiss pricing study we could find, Beyondweb's survey of Swiss web agencies, publishes an hourly rate of CHF 120–250 (average CHF 166, based on only ten observations) — but it prices websites and web-agency work, not applications, and we say so rather than stretch it to cover a different product. Our article on cost treats that study, and the gap it doesn't cover, in full.

What we can tell you honestly is our own price. In our web application cost calculator, an MVP starts at CHF 25,000, a full product at CHF 72,500, and a multi-module system with roles, a public API and an admin panel at CHF 250,000. That's our own starting price, not a market reading — worth saying because the two are easy to conflate. Testing, documentation and maintenance are priced into it as line items from the start; we aren't claiming to beat a benchmark we can't cite.

Four things usually push a quote toward the top of a range, and none of them is a choice of framework: the number of roles with separate permissions, integrations with systems you don't control (warehouse, accounting, payments, couriers), migrating data from what you use today, and accessibility and security requirements where the application serves external customers. The last two are the ones most often missing from a first quote and reappearing mid-project. If you're comparing offers, check first whether each one even lists these four items.

Where to start

Start with an MVP, not the full system. An MVP covers only the core user journey — no admin panel, no advanced settings, no variants. In our own pricing, each level roughly triples the scope, so the difference between "let's build one thing first" and "let's build everything" is bigger than the difference between suppliers. How to plan an MVP so it doesn't turn into a wish list is covered in what is an MVP for a web application.

Describe the process before you describe the features. A feature list comes from a process, not the other way round. We break the project stages down, from analysis to launch, in the web application development process, and you'll find the list of what to prepare on your side in the checklist for a business owner.

Work out the order of magnitude before you ask for a quote. That's what the web application cost calculator is for; if you don't yet know whether you need a web application, a mobile app or just a website, start with the quiz. All of these tools are in our tools section.

Once you know what you want to build, our web application development offer describes what working with us looks like. For the wider context — every topic connected to web applications — see our guide to web applications.