Web app vs website: the short answer
A website is a set of pages that tells every visitor the same thing. A web application is software in the browser that knows who is using it, keeps what they do and changes what it shows as a result. If visitors read and then contact you, you need a website. If they log in, save something or move a job through steps, you are commissioning a web application.
A contact form doesn't turn a website into an application. A single login does. From that moment the system has to remember people, protect their data and decide who may see what.
This guide is for founders and operations leads at UK and EU companies of 10 to 200 people. You're writing a brief and can't tell which one you're asking for, or two suppliers have quoted the same brief as two different jobs. Below are a four-question test, two of our own projects on either side of the line, and what changes once you cross it.
We build both: web applications such as portals, booking platforms and dashboards, and websites for firms that mainly need to be found and contacted. As our websites page says, most sites we build launch alongside a form, a booking flow or a portal. So the question is rarely which one. It's where one ends and the other begins.
What a website is, and what a web application is
The two differ in what they remember about each person using them. A website publishes. A web application keeps records that change because people use it.
| Website | Web application | |
|---|---|---|
| What it's for | Telling visitors about you, and getting them to get in touch | Letting people do a job: book, order, apply, track, approve |
| Who uses it | Anyone, usually without an account | Signed-in users, often in different roles, plus your staff |
| What it remembers | Your content. A form passes its message on to an inbox | Accounts and records, with their history, in a database |
| Examples | A builder's portfolio, a restaurant's menu and hours, a law firm's service pages | A customer portal, a booking platform, an online shop, an internal dashboard |
| What people call it | Site, brochure site, landing page | Portal, platform, dashboard, members' area, client area, system |
Check the last row against your own brief. If it says "portal", "platform", "dashboard" or "client area", you are asking for an application, even if the heading says website.
An online shop belongs in the application column, because every order and payment is a record. Most shops rent that application from Shopify or a similar platform instead of building it. Our guide to Shopify vs a custom shop covers when that changes.
The technology isn't the difference
Many guides say a web app is built with React or Angular and a website with plain HTML. That describes fashion, not the difference. The same tools build both.
The UK government builds its web applications HTML first. You can renew a passport online and track the application with its reference number. The GOV.UK Service Manual says every government service must follow progressive enhancement: each page works in plain HTML, and JavaScript only adds to it. It also tells teams not to build a service as a single-page application, the style many guides treat as the mark of a web app.
The reverse is true too. A marketing site can run plenty of JavaScript for animation and still be a website, because every visitor sees the same thing.
So don't ask a supplier which framework they'd use. Ask what the system has to remember, for whom, and who else may see it.
A four-question test
Answer these about the thing you want built. Each yes is an application job.
- Does it need to know who each person is? Accounts, logins, "my bookings".
- Does it store what people create or change? Orders, uploads, applications, notes.
- Do different people see or do different things? Customers see their own records, staff see everyone's, a manager approves.
- Does a job move through steps over time? Requested, confirmed, paid, cancelled, refunded.
Four noes: you need a website. The only thing it keeps is your content, and enquiries go to a person.
One or more yeses: ask whether that job works the same way in every business. Table bookings, appointments and card payments do, and products already handle them well. Our guide to custom software vs off-the-shelf sets out that test in full. Build an application only when the job is your own process, where the way you do it is part of why customers choose you.
Pelikani and Guidoo: one project on each side of the line
Two of our projects answer yes to all four questions, and only one of them needed an application built.
Pelikani Kacurrel is a seafood restaurant in Zogaj, on Lake Shkodra in northern Albania. Its site fills tables on an ordinary evening and takes enquiries for weddings and celebrations of up to 150 people. It has a menu, a gallery, reviews and a separate path for events.
Table reservations answer yes to every question on the test. But the restaurant already ran a booking system that did the job, so the site sends diners into it. We built a website and left the application to the product the restaurant already used.
We made the same call for Shkodra Shore, a villa on the same lake, whose site hands guests to the booking channel it already had. As that case study says, not every property needs its own booking engine.
Guidoo, an Albanian travel platform, is the opposite case. Albanian holiday packages are sold agency by agency, so comparing them means calling around. Guidoo puts packages from licensed agencies across the country into one search. It prices flights, hotel, transfers and meals as one figure, and takes payment online with instalments.
As its case study puts it, the hard part wasn't the booking flow. It was making packages from different agencies genuinely comparable. That comparison is the point of the platform, so it had to be built. Our guide to building a booking platform explains what that involves.
What changes once people log in
Once people log in, you run software that holds other people's data. The build gets bigger, but the bigger change is what you answer for after launch.
| Website | Web application | |
|---|---|---|
| What "finished" means | Every page approved and live | Every state designed: empty, loading, error, permission denied |
| Where the design starts | The buyer and the pages they read | The data model: what a customer, an order or a booking is, and how they connect |
| Main security risk | Out-of-date software, and spam through forms | One user seeing or changing another user's records |
| Personal data | Enquiries passing through a form | Accounts and records you must protect, and delete on request |
| After launch | Content edits and software updates | Monitoring and releases, plus support for users who can't log in |
| How it fails | A page looks wrong | The wrong person sees the wrong data, or a slot is sold twice |
Access control is the risk that arrives with the login. OWASP, a non-profit security foundation, ranks broken access control first in its 2025 Top 10 of web application risks. It found some form of it in every application it tested. Its own example is a user who edits the account number in the address bar and sees someone else's account.
A site with no accounts can't have that bug. An application has to check, on every request, that this person may see this record. For each role, ask two separate questions: what may this person change, and what may they see?
Personal data becomes something you hold. The ICO's security guidance says only people you've authorised should be able to access or change it, and that you must test those measures regularly. A breach that puts people at risk must be reported to the ICO within 72 hours of your becoming aware of it.
When a customer asks you to erase their data and the right applies, you must respond within a month. EU companies have the same duties under the GDPR, so the application needs a way to meet each one from the start.
The second release is where applications break. Our web applications page puts it this way: the data model was drawn for the demo, then reality arrives. A client has two locations, an order needs splitting, a user belongs to two teams.
A website absorbs change a page at a time. An application built on the wrong data model has to be rebuilt.
Four shapes most businesses end up with
Most businesses end up with one of four shapes, and only two involve building an application.
| Shape | What gets built | Example |
|---|---|---|
| Website only | Pages, plus a form that reaches a person | ES Construction, a London builder whose quote requests go by phone, email or WhatsApp |
| Website that hands off to a product | Pages, plus a link or widget into a booking system or shop platform | Pelikani, Shkodra Shore |
| Website plus your own application | A public site, and a separate application for customers or staff | A distributor with a portal where trade customers reorder |
| The application is the product | The application, with public pages in front of it | Guidoo |
In the third shape, keep the two apart. The public site should load fast, be easy for your team to edit, and have every page readable by search engines. The application sits behind a login, often at its own address, and changes through planned releases.
Don't build the public pages inside the application. Google processes JavaScript apps in three phases: crawling, rendering and indexing. It still recommends server-side rendering or pre-rendering, partly because not all bots can run JavaScript.
When Vercel studied AI crawler traffic on its network in December 2024, the crawlers behind ChatGPT and Claude, among others, didn't run JavaScript. Google's Gemini, which uses Googlebot, did. A services page that only appears after a script runs may be invisible to the AI tools your buyers now ask.
When you don't need a web application
You don't need one when a website plus an inbox, a product or a phone call already does the job. Skip the build in these cases:
- Visitors only get in touch. A form that reaches a named person is enough, and it's easier to keep working.
- The application job is standard. Bookings and payments have products that do them well, so link to one.
- A "client area" would only hold a few documents. A shared folder with access set per client, in tools you already use, may do the job without accounts you have to secure.
- Nobody has proved they want it yet. Take the first orders by phone and a spreadsheet, and let the questions customers ask shape the first version. When you do build, our guide to what an MVP should include covers what comes first.
The reverse also holds. If the application is your product, the website in front of it can be small. A few clear pages and a way in are enough until customers arrive.
Write one line per job before you ask for a quote
A website's scope is counted in pages and content. An application's is counted in who uses it, what it records and the steps each job goes through. Send a brief that doesn't say which you want, and suppliers will quote different jobs.
That is one reason quotes for "a website" can be so far apart. Our guide to what sets the price of a website in the UK shows how to read them side by side.
Before you send a brief, write one line for each thing the site must let someone do. Next to each line, note who does it, what the system must remember afterwards, and who else may see it. Where the last two are blank, that line is website work.
The rest are application jobs, and for each one, check whether a product already does it. Send that list with your brief, and every supplier will be quoting the same job.
Questions
Do we need a mobile app as well as a web app?
Usually not at first. A web application already works in a phone's browser. Built as a progressive web app, it can also be installed on the home screen and work offline. Since iOS 16.4 in 2023, an iPhone web app added to the Home Screen can ask to send push notifications. Build a native app when you need something the browser can't do well, or when customers expect to find you in an app store.
Can we start with a website and add a web application later?
Yes, and it's often the right order. Keep the website on your main domain and give the application its own address, such as app.yourcompany.com. Then neither has to be rebuilt when the other changes. Decide early where customer data will live, and open the hosting and database accounts in your company's name from the start.
Who owns a web application once it's built?
You should, and an application has more to own than a website: the code, the database, the hosting and the user data. When we build, the code and repository, the hosting and the documentation sit in your own accounts and move to you at handover. Ask any supplier to put the same in writing. Then check that you could export your users' data without their help.
How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.