Both open in a browser, and many projects are a mix. The useful distinction is how much of the thing is a tool rather than a document.
| Aspect | Website | Web application |
|---|---|---|
| Main purpose | Present information, generate enquiries | Let users perform tasks |
| Content | Mostly the same for everyone | Depends on the user and their data |
| Accounts | Rare | Common, often with roles |
| Data stored | Little: form submissions | A lot: records users create and change |
| Typical examples | Company site, portfolio, blog | Booking system, dashboard, CRM, online banking |
| Main risks | Out-of-date content, slow pages | Data integrity, permissions, security, scaling |
Why it matters for budgeting
A web app needs a database, rules about who can see and change what, validation of everything users send, testing of workflows and a plan for what happens when something fails. None of that is visible in a mock-up, and all of it takes time. Treating an application as a website is the most common reason such projects are underestimated.
Many projects are both
A company site with a members’ area, a shop or a booking flow is a website with an application inside. It helps to name the application part explicitly and plan it separately from the pages, because that is where most of the effort goes.
If you cannot say whether yours is one or the other, describe what a user does from arrival to finish. Every step where they change something or the system remembers something is application territory.