The short answer
Web applications are usually grouped two ways: by the job they do, such as a customer portal, an internal tool, a marketplace or a software product, and by how they are built, such as a multi-page app, a single-page app or a progressive web app. The first grouping decides what you are buying. The second decides how it behaves and what it costs to run.
Most business projects are one of six or seven recognizable types, and naming yours early saves weeks. It tells you which features are standard, which questions a developer needs answered, and which of the examples below you can point at and say "like that, but for our customers".
Types by the job they do
This is the grouping that matters in a first conversation, because it sets the feature list.
| Type | What it does | Who uses it | Features you can expect |
|---|---|---|---|
| Customer portal | Lets customers see their own data and do their own admin | Your customers, plus staff who support them | Login, roles, documents, messages, billing history, notifications |
| Internal tool | Replaces spreadsheets and manual steps inside the company | Staff, often one team | Records, permissions, approvals, exports, an audit trail |
| Software product | Sold as a subscription to many companies | Customers who sign up themselves | Sign-up, plans, payments, separate data per company, usage limits |
| Marketplace | Connects two sides and handles the transaction | Buyers and sellers | Two account types, listings, search, payments, payouts, reviews |
| Booking or scheduling | Turns availability into confirmed appointments | Customers and staff | Calendars, rules, reminders, deposits, rescheduling |
| Dashboard or reporting | Pulls data together and shows what matters | Managers and analysts | Data connections, charts, filters, scheduled reports, access control |
| Online store | Sells products or services directly | The public | Catalog, cart, checkout, tax and shipping, orders, returns |
Real projects often combine two. A booking app for a clinic is also a customer portal. A marketplace is a store with a second side and payouts. Combinations are fine, as long as you name both, because the second one is where budgets get missed. Our guide to customer portal development covers the most common of these in detail.
Types by how they are built
The second grouping is about architecture. It changes speed, offline behavior, search visibility and hosting cost more than it changes the feature list.
| Approach | How it works | Strengths | Trade-offs |
|---|---|---|---|
| Multi-page application | The server sends a new page for each request | Simple, easy to make search friendly, predictable | Every interaction is a page load, which feels slower inside a tool |
| Single-page application | The browser loads one shell, then swaps content using data from an API | Fast, app-like interactions after the first load | Heavier first load, and search visibility needs deliberate work |
| Progressive web app | A web app that can be installed and works partly offline | Reaches phones without an app store, works in weak signal | Some device features are limited compared with a native app |
| Hybrid, static pages plus an API | Public pages are pre-built, the app behind login talks to an API | Fast public pages and a clean separation of concerns | Two things to build and deploy instead of one |
For most business applications the hybrid pattern is the practical default: marketing pages that load instantly and can be found in search, and an application behind login built for the people using it all day. Our explainers on single-page applications and progressive web apps cover those two in depth.
What every type needs anyway
Whatever the type, the same unglamorous parts appear in almost every build, and they are the ones left out of early estimates. Assume all of them are in scope until someone says otherwise.
- Accounts and roles. Sign-in, password reset, invitations, and at least one level of permission.
- An admin area. Someone on your side has to fix bad data, reset a user, or answer a support question without a developer.
- Notifications. Email at minimum, with rules for who gets told what and how to stop it.
- Search and filtering. Any list of records grows past the point where scrolling works.
- An audit trail. Who changed what, and when. Cheap to add early, painful to add later.
- Reporting or export. People will want the data in a spreadsheet no matter how good the screens are.
- Hosting, backups and monitoring. Running costs and an owner, from the day it launches.
If a quote does not mention these, ask where they sit. They are not extras, they are the difference between a demo and something a team can use on a Monday morning.
How to tell which type you need
Answer these five questions and the type is usually obvious.
- Who logs in? Nobody means you need a website. Customers means a portal or a product. Staff means an internal tool.
- Where does the data live today? If the answer is a spreadsheet and an inbox, the first version is an internal tool that replaces exactly that.
- Does money change hands inside it? Payments turn a simple app into a store, a product or a marketplace, and add tax, refunds and disputes.
- Is there more than one kind of user? Two sides means a marketplace, and roughly twice the work of one.
- Does it need to be found in search? If yes, the public part needs real pages, whatever the app behind login is built with.
If you are still unsure whether you need an application at all, our comparison of a web app and a website is the shortest way to settle it, and what a web application is covers the basics.
What the type does to cost and timeline
The type sets the floor, and the details set the rest. Every one of these pushes a project up:
- Number of user roles. Each role needs its own screens, permissions and testing.
- Payments. Plans, refunds, failed payments, invoices and tax are all work after the first successful charge.
- Integrations. Every outside system is a contract you do not control, and the failure cases take longer than the happy path.
- Data migration. Moving years of messy records is often the largest single task, and the easiest to underestimate.
- Compliance and audit needs. Logging, retention and access control add work across the whole app.
- Offline or real-time behavior. Live updates and offline support are features, not defaults.
Rather than guessing from a type alone, read how much a web application costs for the full picture, then price your own list of drivers against it.
Worked examples
Three short examples of how a description becomes a type.
- "Our clients email us for updates and we resend the same documents." That is a customer portal: login, documents, status, notifications. The measure of success is fewer emails.
- "Three people keep a shared spreadsheet of jobs and it goes wrong every week." That is an internal tool: records, permissions, a status workflow and an audit trail. The measure is fewer mistakes and no more version conflicts.
- "We want to charge other companies to use the system we built for ourselves." That is a software product: sign-up, plans, payments and data kept separate per company. The measure is customers who renew.
Notice that each one names a problem, a user and a way to tell whether it worked. That is the minimum a developer needs before quoting anything.
Next step
If you can say who logs in and what they need to do, we can tell you which type of application you are describing, what a sensible first version contains, and what it takes to build. Send that description to us on the contact page, or see how we work on the web application development page.