Web app vs website: which do you actually need?
The distinction matters because it changes cost, timeline, and the technology you should pick.
Short answer
A website presents information; a web application lets people do work. If users mainly read and navigate, you need a website. If they log in, enter data, and get a result back that persists, you need a web application. Web apps typically cost several times more because they require accounts, a database, permissions, and ongoing operation.
The practical distinction
A website is primarily read-only: marketing pages, articles, documentation, a portfolio. Its job is to be found, be fast, and communicate clearly. A web application is interactive and stateful: users sign in, create and change data, and come back to something that remembers them.
The line blurs in practice (most marketing sites have a contact form, and most apps have marketing pages), but the centre of gravity determines how you should build it.
Why it changes cost so much
A website is mostly content, design, and performance work. A web application adds authentication, a database, permissions, validation, error states, background jobs, and an operational burden that never ends. That is why an app is usually a multiple of a site in both initial cost and ongoing spend.
A simple test
- Does a user need an account? → application.
- Does the product need to remember what a user did last time? → application.
- Is the main goal to be found in search and explain something? → website.
- Would a spreadsheet plus a landing page solve it for now? → website first.
A common, cheaper path
Many products do not need to start as an application. A fast website that explains the offer, plus a manual process behind the scenes, will validate demand at a fraction of the cost. Build the application once you know which parts people actually use.
Common questions
Is a web app harder to rank in search than a website?
- Often yes, because content behind a login cannot be indexed and heavy client-side rendering can hide content from crawlers. The usual solution is to server-render public pages and keep marketing content outside the authenticated area.
Can one project be both?
- Yes, and most are. The practical approach is a fast, server-rendered public site for content and SEO, and an application section behind login, often in the same codebase.
What technology suits each?
- For both, we typically use Next.js and TypeScript: it server-renders content pages well for SEO and also supports a full application. The choice matters less than rendering public content on the server and keeping the client light.