A web app is interactive software accessed through a web browser. Unlike a static website that only displays information, a web application allows users to create accounts, submit data, and complete workflows. The server remembers your actions and updates the interface in real time.
Gmail, Notion, and Figma are web apps. A law firm’s “About Us” page is not.
I build web apps for clients as a solo developer. The line between a site and an app gets fuzzy in the middle. That fuzziness is where founders waste budget. They ask for a “website” when they actually describe a logged-in dashboard with five roles. That mismatch is expensive if you do not catch it before the contract.
What Counts as a Web App?
A web app has persistent user state, interactive workflows, and a backend that outlives any single page view. You sign in. Your actions change stored data. Other users or devices can see those changes.
A brochure site might have a contact form. Nobody calls it an app if the form email is the only server-side behavior.
The quick test I use on scoping calls is simple: describe what a logged-in user can accomplish in one sentence. If the answer is “read information,” you probably need a website. If the answer is “complete a task that leaves data behind,” you are in web app territory.
| Signal | Website | Web app |
|---|---|---|
| Primary job | Inform, persuade, publish | Let users complete tasks |
| User accounts | Optional, often none | Usually required |
| Data | Mostly static content | Created and updated by users |
| Backend | CMS or none | APIs, database, business logic |
| Example | Company homepage, blog | CRM, dashboard, booking tool |
How a Web App Works
At a high level, every web app is the same shape. Browser UI talks to an API. The API talks to a database.
You click or type in the browser. JavaScript sends a request to a server. The server checks permissions, runs rules, reads or writes a database, and sends back a response. The page updates. That loop might happen once to submit a form. It might happen hundreds of times as you drag items on a Kanban board.
Three pieces matter:
- Frontend: what you see and click. Often React or Vue. Single-page apps load once and swap views in place. Multi-page apps fetch new HTML on each navigation. Both can be web apps.
- Backend: the brain. Handles auth, validation, payments, email, integrations. I usually work in Python (FastAPI) or Node. The language matters less than whether the API fits the product’s actual workflows.
- Data store: where user records live. PostgreSQL, MongoDB, or a managed service. If the product has no durable data, question whether you need an app at all.
Progressive web apps (PWAs) add install-to-homescreen and offline caching on top of this model. They are still web apps. The delivery layer is different, not the core definition.
Types of Web Apps You Will Hear About
Labels overlap. These are the ones that come up on real projects.
Single-page applications (SPAs) load one HTML shell. JavaScript handles navigation. Feels fast after the first load. Good for dashboards and tools where users stay inside one session. Uninote, a meeting-notes product I worked on, is this pattern. Recordings, transcripts, and workspace views swap without full page reloads.
Multi-page applications (MPAs) fetch a new page from the server on each click. Simpler mental model, often better default SEO for content-heavy areas. Many products mix both. Marketing site as MPA, logged-in product as SPA.
SaaS web apps sell access to the software itself. Slack, Linear, most B2B tools. Multi-tenant architecture means many customers, isolated data, billing, and roles.
Internal apps serve one company. Inventory trackers, approval workflows, ops dashboards. Less glamorous. Often where custom web apps pay off first because no off-the-shelf tool fits the exact process.
Marketplace and aggregator apps connect two sides or pull data from many sources. Look Estate is a listings aggregator I built. It scrapes multiple property sites, normalizes the data in a backend, and serves search and filters in the browser. Users do not “read listings.” They find them with tools.
If you are picking a stack for a new app, programming languages used in web development maps languages to these shapes without pretending one size fits all.
Web App Examples
Consumer and productivity: Google Docs for collaborative editing. Spotify web player for account and library state. Trello for boards that persist per user.
B2B SaaS: Salesforce, HubSpot, Figma. Login, permissions, data that belongs to an organization.
From my own work:
- Uninote: record meetings, generate transcripts, share notes across a team. Realtime status, calendar hooks, large media uploads. Classic web app complexity hiding behind a simple UI.
- Look Estate: search, filter, paginate listings aggregated from external sources. The “app” part is the query layer and saved behavior, not the HTML brochure wrapper.
The pattern across all of them is simple. Remove the server and the product stops working. That is the practical definition. It is more useful than debating whether something is technically an app.
When you need a web app?
Build a web app when the product is the workflow, not the explanation of it.
You need a web app if:
- Users must have accounts and see their own data.
- Multiple people collaborate on the same records with permissions.
- The value is a tool to configure, calculate, upload, approve, or track.
- You are replacing a spreadsheet-and-email process that already has named steps and owners.
- You plan to charge for access to functionality.
A website is enough if:
- The goal is credibility, SEO, lead capture, or publishing content.
- “Contact us” or “book a call” is the only conversion.
- Nothing important changes per user after they land on the page.
Founders often arrive wanting a web app because apps feel serious. Sometimes they need validation first. A landing page, a waitlist, a manual concierge service.
What a Web App Costs
There is no single number. A focused single-workflow app with auth and one integration might ship in 4 to 8 weeks on a solo build. A multi-module SaaS with billing, admin, and mobile-responsive complexity is a different project entirely.
Cost drivers that actually move the estimate:
- Number of distinct user roles and permission rules.
- Integrations for payments, CRM, calendar, or third-party APIs.
- Realtime features like live updates or collaborative editing.
- Data migration from an existing system.
- Compliance for health, finance, or enterprise SSO.
Limitations and Tradeoffs
Web apps are not automatically the right choice.
Browser tab fatigue. Users already live in dozens of tabs. If your product could be a browser extension, a Slack bot, or a mobile app with offline needs, forcing everything into a web UI can hurt adoption.
SEO for the logged-in product. Public marketing pages index fine. The core app behind login usually does not. Plan content and landing pages separately.
Maintenance is ongoing. Auth, dependencies, hosting, bug reports, feature requests. A website on a static host is cheap to ignore. A web app is not.
Overbuilding before proof. I have scoped calls where the “MVP” included admin analytics, notification preferences, and four user types before anyone had used version zero. That is a web app spec built on a website-stage risk profile. Start with the one workflow that proves the idea. Add the rest when usage data exists.
Conclusion
The useful takeaway is smaller than the taxonomy. A web app is software that remembers what you did and changes what it shows because of it. Everything else is implementation detail.
If you are still deciding what to build, start by defining the core workflow. Prove that people actually want to complete that task before you pay for custom auth, databases, and API architecture.
FAQ
Is a web app the same as a mobile app?
No. A mobile app is installed from an app store and runs natively on iOS or Android. A web app runs in a browser. Many products offer both and share one backend. You can wrap a web app in a native shell (hybrid), but that is a distribution choice, not a different product category.
Is Netflix a web app?
Yes, on netflix.com. You log in, browse a catalog personalized to your account, and stream content. The same product also exists as native TV and phone apps. The web version is still a web application. Account state, recommendations, and playback all depend on server-side logic.
What is a progressive web app (PWA)?
A PWA is a web app that uses modern browser features to feel more app-like. Install icon, offline caching, push notifications in some cases. Instagram’s mobile website and many shopping carts use PWA techniques. It is still a web app under the hood.
Can a website become a web app later?
Often, yes. A common path is launching a marketing site and manual backend (email, spreadsheet), then replacing the manual steps with a logged-in product when demand is proven. The risk is painting yourself into a corner with a CMS or template that cannot grow into real application logic. Pick a stack early if you already know the workflow is coming.
Do I need custom code or can I use no-code?
No-code tools like Bubble or Webflow with memberships can ship simple web apps fast. Custom code wins when you need unusual logic, heavy integrations, performance at scale, or ownership of the codebase.
