Introduction
Ask five developers to explain the difference between a web app and a website, and you’ll get five confident, slightly different answers. Most of them will say a website is static and a web app is dynamic. That test stopped working around the time WordPress started generating every page on request, which makes almost every WordPress site “dynamic” by that definition and yet nobody calls a WordPress blog a web app.
Web app vs website isn’t really a question about content. It’s a question about state: does the interface need to remember what a specific user just did and change its behavior because of it, or does it just need to serve the same page to whoever shows up? Get that wrong before you brief a build, and you end up paying for infrastructure you didn’t need, or discovering three months in that the “simple website” now needs authentication, a database schema, and session handling nobody scoped for.
Pedals Up is an AI-native product engineering company that builds web apps, mobile apps, and SaaS products for startups and scale-ups across the US, UK, and UAE. This exact confusion shows up in a good number of early client conversations, usually because a website got briefed when what the business actually needed was an app, or the reverse.
Why "static vs dynamic" stopped being a useful test
In the 1990s, the distinction was easy. A website was a folder of HTML files. A web app, if the term even existed yet, was something closer to a desktop program that happened to run in a browser.
Then two things happened. Content management systems made every site “dynamic” in the sense that pages get assembled from a database on request. And AJAX, popularized by Gmail in 2004, let pages update themselves without a full reload, which made the browser feel like it was running software instead of displaying documents.
Static vs dynamic never recovers from either of those changes. A Next.js marketing site is technically dynamic and is still, functionally, a website. Wikipedia serves database-generated pages to millions of people and is still a website, because every visitor gets the same article regardless of who they are or what they did last time. Gmail is the opposite: the page you see depends entirely on your account, your unread count, and what you clicked thirty seconds ago.
That’s the actual line. Not what generates the page. What the page has to remember.
The real dividing line: does it need to hold state
What does “stateful” mean for a web app? A stateful interface tracks something specific to one user’s ongoing session and behaves differently because of it, things like a shopping cart, a dashboard filtered to your data, a document you’re mid-edit on, or permissions that change what you can even see. A stateless interface shows the same thing to everyone and doesn’t need to remember any individual visitor between requests.
Almost every real disagreement about “is this a website or a web app” collapses once you ask that one question instead of arguing about frameworks.
This is also where rendering strategy actually matters, and where a lot of the confusion comes from. Google’s own guidance on rendering lays out the tradeoff plainly: server-side rendering gets content in front of users and search crawlers faster, while client-side rendering front-loads a heavier initial payload in exchange for an interface that can update itself without round-tripping to the server for every interaction. A marketing site almost always wants the first. A tool your users log into and use for twenty minutes at a stretch usually wants some of the second, even if it renders the shell on the server for speed.
Progressive web apps sit in the middle, which is exactly why people misuse the term as a tiebreaker.
Is a progressive web app a website or a web app? A progressive web app is a website built with additional browser APIs, service workers for offline caching, a manifest that lets it be installed on a home screen, and push notifications that let it behave more like a native app without leaving the browser’s delivery model. MDN’s definition is explicit that a PWA still gets the web’s discoverability and shareability through a normal URL. It’s a website that opted into app-like capabilities, not a third category.
Why the label decides your cost, hosting, and who you hire
Calling something the wrong name isn’t just semantics. It changes what you actually have to build.
A stateless website needs content, a CDN, and not much else on the backend. A stateful web app needs authentication, a database, session management, and usually an API layer connecting the two, along with a bigger security surface because there’s more for an attacker to touch once users can log in and store data. Client-rendered apps also tend to lose ground on organic search unless someone deliberately handles server rendering for the pages that need to be indexed, which is a real tradeoff, not a footnote.
The failure mode I see most often runs one of two ways. A founder briefs “just a website” for something that turns out to need user accounts and saved state, and the build balloons mid-project because nobody scoped a database or an auth flow. Or a team over-builds a brochure site as a fully client-rendered single-page app, and it loads slowly and ranks poorly for a business that only ever needed five fast, indexable pages.
Getting that classification right, before a line of code gets written, is exactly the kind of decision worth making with an engineering partner rather than guessing. It’s the first real conversation in most of Pedals Up’s web app engagements, because the architecture decision made in week one is the one that’s hardest to undo in month six.
How to actually decide what you're building
Skip the label and ask what the product needs to do. Does it have to remember a specific user across visits and change behavior for them? Does it need to update in real time without a page reload? Does ranking on Google matter more than the interface feeling instant?
Do I need a web app or a website for my startup? If your product’s core job is presenting the same information to every visitor, whether that’s your services, your pricing, or your content, you need a website, and building it as a full client-rendered app will only cost you speed and search visibility. If your product’s core job is letting a specific user do something with their own data over time- a dashboard, a booking system, a tool they log into- you need a web app, and trying to fake that with a static site will hit a wall the first time you need real authentication or persistent data.
Most real products end up as both: a website for the pages that sell the product, and a web app behind the login for the part that delivers it.
Conclusion
The label doesn’t matter. What the interface has to remember and react to does. Decide that before you write a brief, and the rest, hosting, framework, team, cost, follows from it instead of getting discovered halfway through the build.
Next time someone asks whether they need a website or a web app, ask them one question back: does this need to remember you?
If you’re not sure whether what you’re planning to build is a website, a web app, or something that needs to be both, we can walk through the architecture with you before you write a brief. Talk to our team.
Frequently Asked Questions
What’s the actual technical difference between a web app and a website?
A website serves the same or similar content to every visitor and doesn’t need to remember who’s looking at it. A web app tracks a specific user’s session and changes what it shows or does based on that user’s data and actions. The old “static vs dynamic” test doesn’t hold up anymore because most modern websites are technically dynamic too.
Is a PWA a website or an app?
A progressive web app is a website that adds service workers, an installable manifest, and push notifications so it can work offline and be added to a home screen. It’s still delivered through a browser and a URL, so it’s closer to an enhanced website than a separate category.
Can a website be turned into a web app later without a full rebuild?
It depends on how it was architected from the start. A website built on a static site generator or a simple CMS usually needs a real backend, authentication, and a database added before it can hold user-specific state, which is often close to a rebuild. A site built with a framework that already supports server-side rendering and an API layer can usually add app-like features incrementally.
Does a web app cost more to build than a website?
Generally yes, because a web app needs authentication, a database, session handling, and ongoing maintenance for all of that, where a website mostly needs content and hosting. The gap depends heavily on how much state the app has to manage and how many user roles or permissions it needs to support.
Why do developers disagree about the difference?
Because most definitions in circulation use “static vs dynamic,” a distinction that stopped mapping to reality once content management systems and static site generators made almost everything technically dynamic. Developers who’ve internalized the outdated test give inconsistent answers because the test itself no longer describes anything real.
The label doesn’t matter. What the interface has to remember and react to does. Decide that before you write a brief, and the rest, hosting, framework, team, cost, follows from it instead of getting discovered halfway through the build.
Next time someone asks whether they need a website or a web app, ask them one question back: does this need to remember you?
If you’re not sure whether what you’re planning to build is a website, a web app, or something that needs to be both, we can walk through the architecture with you before you write a brief. Talk to our team.
