Types of Web Applications, With Examples of Each

"Web application" covers everything from a booking form to a product sold by subscription, which makes the phrase almost useless in a first conversation. This guide splits web applications into the types people actually build, by the job they do and by how they are built, with examples and the questions that tell you which one your project is.

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.

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.

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.

As a guide to our own prices: an internal tool or MVP typically costs $8,000 to $15,000, a standard web app or customer portal $15,000 to $30,000, and marketplaces or multi-tenant SaaS platforms start around $30,000 and are quoted individually.

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.