Web App vs Website: How to Choose the Right One

A website delivers content: pages that every visitor sees more or less the same way. A web app processes data and remembers who is using it: each user logs in, sees their own information and completes tasks. If your project needs accounts, roles, payments, dashboards or automated workflows, you are building a web app, whatever you call it internally. If visitors mainly read, compare and contact you, you need a website.

The line is blurry in practice, and the choice affects budget, timeline, hosting and legal duties. This guide gives you a clear test, real examples, the cost and maintenance consequences, and the Swiss data protection points that founders often discover too late.

TL;DR

• A website presents information; a web app lets each user do something with their own data, such as manage records, book, pay or collaborate.
• The practical test: if you need logins, roles and permissions, customer portals or automated processes, you need a web app, not a bigger website.
• Web apps cost more to build and need ongoing care (updates, monitoring, security), while a simple website is cheaper to run.
• In Switzerland, a web app handling personal data brings server location, transparency and privacy-by-design questions into the architecture from day one.
• Many successful products combine both: a marketing website in front, a web app behind the login.

The difference in one minute

Think of a website as a magazine and a web app as a tool. A magazine is read. A tool is used, and what it does depends on who holds it.

Technically, a website serves content, while a web application processes data and manages state for each user. The same Swiss hosting provider notes that the switch becomes necessary once login areas, customer portals, roles and permissions, or automated processes enter the picture.

Here is how that looks side by side.

Criterion	Website	Web app
Main purpose	Inform, persuade, generate enquiries	Let users complete tasks
Typical content	Pages, articles, images, forms	Data, records, dashboards, workflows
Users	Anonymous visitors, mostly	Identified users with accounts and roles
Interaction	Read, click, send a contact form	Create, edit, approve, pay, collaborate
Caching	Easy: pages can be stored and served fast	Hard: much of the output is personal and changes constantly
Maintenance	Light: content updates, occasional security patches	Continuous: features, monitoring, dependency updates
Data protection weight	Cookies, contact forms, analytics	Personal data stored, processed and shared with third parties
Typical build effort	Days to weeks	Weeks to months

Examples that make it concrete

Clearly a website: a law firm presenting its practice areas, a restaurant with a menu and a booking phone number, a portfolio, a company blog, a landing page for an event.

Clearly a web app: an online banking portal, a project management tool, a booking system where staff manage calendars, a customer portal where clients download their own invoices and contracts, an internal dashboard that pulls numbers from your ERP.

In between: an online shop. The storefront behaves like a website (product pages, content, search engine visibility), but the cart, checkout, customer account and order management are application logic. Large platforms like Amazon or Facebook are web apps with public pages attached. The question people ask, whether they are a website or a web application, has the answer: both, and that is normal.

One developer view circulating online is that the distinction barely exists, since both run in a browser. That is true at the delivery layer. It stops being true when you have to budget, secure and maintain the thing, because the work behind a login is a different kind of work.

Five signs you need a web app

You do not need to settle the terminology. Check whether any of these apply to your project:

1. Users have accounts. Not just a newsletter signup, but a login where people see their own data.
2. Different people see different things. Roles and permissions: an admin, a manager, a client, a guest.
3. Transactions happen inside your product. Payments, approvals, bookings, signed documents, status changes.
4. Processes should run without manual work. Notifications, imports, invoice generation, syncing with a CRM, ERP or accounting tool.
5. The product is the value. Customers pay for what the software does, not for what the page says.

One yes usually means you are looking at a web app, or at a website with a web app component. Zero yes answers means a well-built website will serve you better and cost less.

What changes when it is a web app

Architecture

A website mostly moves linearly: a visitor requests a page and gets it. A web app tracks state, meaning who the user is, what they did last and what they are allowed to do. The Swiss hosting provider Metanet points out that this shifts the setup toward transaction-based infrastructure that cannot easily be cached, which affects performance and reliability expectations. In plain terms: a slow brochure page is annoying, a slow checkout or a failing login loses money and trust.

Budget

The visible interface is the smaller part of a web app. The larger part is what users do not see: data models, permissions, error handling, integrations, admin tools, backups. This is why quoting a web app like a website leads to disappointment on both sides. Scope it by workflows (what must a user be able to do, end to end) rather than by pages.

A practical way to control risk is to start with an MVP: the smallest version that lets real users complete the single most valuable task. You learn from usage before you invest in everything else.

Maintenance

Websites are simple to look after, with fewer updates and less effort. Web apps need regular care: new features, dependency updates, monitoring, security fixes. Plan for this before launch. A web app without an owner after go-live slowly decays, and that is where many agency relationships turn sour.

At Ampersand, ongoing care is its own offer: our Run & monitor plan is listed at CHF 750 per month on our pricing page, so you can see what running software looks like as a line in your budget rather than a surprise.

Integrations

Most useful web apps talk to other systems: shop, CRM, ERP, accounting, payment providers. A study of Swiss online retailers by ZHAW found that the online shop is relevant for 70 percent of the surveyed merchants as a sales channel, and for national providers, service quality and exclusivity are how they compete against global platforms. One way to act on that: build tooling that connects precisely to the systems you already use, something a standardized foreign tool will not do for you.

Swiss specifics: data protection is part of the design

A brochure website collects little. A web app often stores names, emails, documents, behavior and payment context. Under the Swiss Federal Act on Data Protection (DSG), personal data must be processed lawfully, in good faith and proportionately (Art. 6). That is not a paragraph for the footer. It shapes what you collect, where you host and which third-party tools you plug in.

Three points worth knowing before you brief a developer:

• Transparency must match reality. The Federal Data Protection and Information Commissioner (FDPIC) updated its cookie guidance in October 2025, and stresses, among other things, that using cookies for personalized advertising may require the consent of the people affected. A privacy policy copied from a template will not describe your actual data flows.
• Think about data flow at the planning stage. The same guidance supports a privacy-by-design approach rather than a checkbox exercise. Claims of cookie-less tracking or anonymous data deserve scrutiny, because modern profiling is judged strictly.
• Hosting and third parties are architectural choices. Where data lives and which external services receive it should be decided early. Public bodies in Switzerland are testing sovereign alternatives and Swiss-hosted infrastructure: the canton of Fribourg, for instance, launched a chatbot hosted on Swiss infrastructure. Your company may not need that level, but you should know your options.

If your product involves high-risk profiling or special categories of data, talk to a data protection lawyer before launch. For the technical side, a useful companion read is this security playbook for queue systems, which shows how a browser-based, multi-user application can be planned with security steps over 30 and 90 days.

Do not force an app into a website

A common and expensive mistake is stretching a content management system until it half-behaves like an application: plugins for memberships, plugins for bookings, plugins for invoicing, each with its own updates and gaps. It works until it does not.

The Swiss federal administration draws a similar line. Its web guidelines distinguish between types of public websites, with standard information sites on one side and specialized applications on the other. The lesson for a business: keep your content site simple, and build the functional part as its own component, linked or embedded through an API or a separate application.

This hybrid is what most mature companies run:

• Website at www: fast, editable by marketing, optimized for search.
• Web app at app or portal: login, data, workflows.
• Integration layer between them and your other systems.

Each part can be changed, replaced or scaled without rebuilding the others. It also keeps you independent: no single tool holds your entire business hostage.

How to decide: a short worksheet

Answer these in a meeting with your team, in writing.

1. What is the one task a user must complete? If it is reading and contacting, website. If it is doing something, app.
2. Who logs in, and what may each person see? Write the roles down.
3. Which systems must it connect to? Name them: shop, CRM, ERP, accounting.
4. What personal data will you handle? List it, and where it will be stored.
5. Who will own it after launch? Name a person and a budget for maintenance.
6. What is the smallest version that proves the idea? That is your MVP.

If you answer questions 2 to 4 with specifics, you are ready for a precise quote. If you answer them with ‘we will see’, spend a short paid consultation or audit on scoping first. It is cheaper than rewriting mid-project.

How we approach it at Ampersand

We are a small Zurich studio that builds websites, web and mobile apps, and platforms for startups and teams. Senior engineers lead each project from the first conversation to handover, so the person who understands your requirements is the person who builds them. That is how we avoid rewritten requirements and mid-project staff changes, and we aim for your independence rather than lock-in.

If you are unsure which side of the line you are on, we can help you scope it honestly, including the cases where a simpler website is the right answer. Our offer covers custom websites, web apps and MVPs, platforms, integrations with shops, CRM and ERP, migrations, automation, and advisory such as a part-time CTO. Our Guidance advisory plan is listed at CHF 799 per month. See what we offer on the pricing page or browse our work to see the kind of projects we deliver.

FAQ

What is the difference between a web app and a website in short?

A website presents information to visitors, while a web app lets each user perform tasks with their own data. Websites are mostly read; web apps are used. The clearest sign is a login with personal content and permissions.

Is Amazon a website or a web application?

Both. The product pages and content behave like a website, while the cart, account, order tracking and seller tools are web application functions. Most large online services combine the two.

Is a web app more expensive than a website?

Usually yes, because it includes data handling, permissions, integrations and testing, and it needs ongoing maintenance. The exact cost depends on the workflows you need, which is why scoping them first matters. A fixed scope for a small MVP keeps the risk contained.

Can I start with a website and add a web app later?

Yes, and it is often wise. Keep the website simple and build the application as a separate component connected through an API. This lets you launch quickly and grow the functional part without rebuilding your public site.

Does a web app need to comply with Swiss data protection law?

If it processes personal data of people, the DSG applies, and it is much more likely to matter than for a simple brochure site. Plan transparency, hosting and third-party services at the design stage, and consult a data protection lawyer for high-risk cases.

Sources

• Website oder Webanwendung? Wann eine Web-App nötig wird (Metanet)
• Aktualisierte Fassung Cookie Leitfaden (FDPIC)
• Datenschutzgesetz, DSG (Fedlex)
• Onlinehändlerbefragung 2024 (ZHAW)
• Le canton de Fribourg lance un chatbot basé sur le LLM de Mistral AI (ICTjournal)
• Regelwerk V04.00 (Swiss Federal Chancellery)