Web app vs website
Both live at a web address and open in a browser. Only one of them has to be right about your data at three in the morning.
The short answer
Build a website when every visitor should see the same thing, and build a web app when people log in and the system must remember what they did.
The line is state, not looks. A beautiful animated marketing page is still a website. A plain grey screen showing your orders and letting you refund one is a web app, and it costs several times more to build safely.
Most projects need both. Confusion starts when a quote for one arrives against a brief describing the other.
Side by side
The differences that change the price and the risk, rather than the ones you can see.
| Dimension | Website | Web app |
|---|---|---|
| What each visitor sees | The same content as everyone else | Their own data, and only theirs |
| Accounts | Usually none | Central, with roles and permissions |
| What breaks when it fails | A page is unavailable | Work stops, and data may be wrong |
| Testing burden | Does it look right and load fast | Does every rule hold for every role |
| After launch | Content edits and occasional redesigns | Monitoring, backups, support, patching |
| Search visibility | The whole point | Mostly irrelevant behind a login |
| Who maintains it | A marketer, with a CMS | Engineers, indefinitely |
| Typical shape | Brochure, blog, documentation | Dashboard, portal, booking system |
- VisitorAnonymous, or signed in
- ContentSame for all, or personal
- RulesWho may see and change what
- DatabaseThe moment it becomes an app
- SupportSomeone owns it after launch
Cross the database box and you have bought a system to run, not a page to publish.
Website
Where it wins
- Cheaper to build, and far cheaper to keep alive for five years.
- Marketing can change the words without waiting for a developer.
- Search engines and answer engines can read it, which is how strangers find you.
- Failures are visible and rarely dangerous. A broken page embarrasses you; it does not corrupt an order.
Where it hurts
- It cannot do anything personal. Every visitor gets the same page.
- Anything transactional gets bolted on with third-party tools, and those seams show.
- Growth by adding plugins ends with a fragile site nobody wants to touch.
- When the business logic really belongs in software, a website postpones the problem rather than solving it.
Web app
Where it wins
- It can enforce your rules, which is the only way to stop people doing the wrong thing at scale.
- Each user sees their own data, which is what turns a service into a product.
- It can talk to your other systems, so work stops being copied between spreadsheets.
- You own the workflow instead of shaping your business around somebody else's tool.
Where it hurts
- Cost does not stop at launch. Monitoring, backups, patching and support are permanent.
- Security matters in a way it does not for a brochure, because now there is data worth stealing.
- Most of it is invisible to search, so it does not bring you visitors on its own.
- It needs engineers available afterwards. An app with nobody maintaining it degrades quietly until it fails loudly.
How to choose
- Choose a website if the job is explaining what you do and getting people to make contact.
- Choose a website if nothing needs remembering between visits, and no one logs in.
- Choose a web app if users have accounts, or if two people must see different things.
- Choose a web app if a rule must be enforced rather than trusted, such as who may approve a refund.
- Choose both, deliberately, if you sell to strangers and serve customers. A marketing site that ranks, and a product behind a login, are different jobs with different owners.
- Choose neither if a spreadsheet and a form still work. Plenty of businesses buy an app to solve a discipline problem, and the app does not fix it.
Systems people log into every day
Questions people ask before briefing an agency
01Is a site with a contact form a web app?
No. A contact form sends a message and forgets it, which keeps you firmly in website territory. You cross the line when the system stores something it must show back to one particular person later. An order history, a saved quote, a booking they can change: each of those needs an app.
02Can one project be both?
Yes, and that combination is normal. Public pages get built for search and speed, while a signed-in area holds the accounts and the rules. Keep them as separate parts sharing a design, so a marketing change on Monday cannot take down the customer portal.
03Does a web app remove the need for a mobile app?
Often, yes. A well-built web app works on a phone browser and needs no store review or install. You still need a real mobile app for offline use, background location, hardware features and push notifications people rely on. Start with the browser and add an app when a specific need justifies it.
04Why is a web app so much more expensive?
Most of the cost is invisible: permissions, validation, error handling, audit trails and the tests proving all of it still works. A website is judged on how it looks and how fast it loads. A web app is judged on whether it is still correct after ten thousand people have used it in ways nobody predicted.
05Can we start with a website and grow into an app?
Yes, and it is a sensible sequence when demand is unproven. Publish the site, add a simple booking or enquiry flow, and watch what people actually do. One trap waits at the end: bolt on enough plugins and the eventual rebuild has to unpick years of workarounds. Agree upfront where you stop extending and start building.
