Website or web app? How to tell which your business needs

“Do we need a website or a web app?” comes up early in many projects, usually when someone sketches a feature that a page can’t do on its own. A dealer wants to see their own orders. A member wants to download reports behind a login. A customer wants a quote that depends on twelve choices.

The answer decides how the project is planned, who builds it and what it costs to run. This guide explains the difference in plain terms, the signs that you need a web app, what a website can do before it becomes one, and the questions to settle before you ask anyone for a quote.

What the difference is

A website is a set of pages. Everyone who visits sees the same home page, the same services and the same contact form. The pages change when your team edits them, and the visitor reads, watches and gets in touch.

A web app runs in the browser too, but it behaves like software. People sign in. What they see depends on who they are and what they did last time. They enter data, and the app stores it, checks it and does something with it. An online banking site and a customer portal are both web apps.

The line between the two is blurry, and that is the useful part. A website can carry app-like features without becoming an app, and a web app usually needs a public website around it to explain what it is. The question to ask is how much of your site has to work differently for each person.

Signs you need a web app

If several of these describe your project, plan for a web app from the start:

• People sign in and see their own information. Orders, invoices, claims, documents, progress or account details that belong to one customer or one member.
• The site runs a process. Applications that go through review, claims that get approved, orders that move through stages, or anything with a status that changes over time.
• There are different kinds of users. Customers, staff, dealers and administrators each need to see and do different things, and someone has to manage who can do what.
• The data lives somewhere else and changes all day. Inventory, pricing, availability or records in another system that the site has to read and write back to.
• The site is the service. Your customers pay for what happens on it, so it has to work every hour of every day and be tested like software.
• People use it daily. A tool your team or your customers open every morning needs to be fast and designed around the work, with the public home page as an afterthought.

If one of these applies and the rest don’t, you probably need a website with one custom feature. That is a different project, and usually a smaller one.

What a website can do before it becomes an app

Many of the features people call “an app” are features of a website. Over the years we have built these on WordPress sites, where the pages stay easy for the client’s team to edit:

• Logins and portals. A shipper login and carrier signup for a trucking platform, a client tracking portal for a freight forwarder, a dealer login for a warranty processor, a parent portal for daycare centers and investor logins for venture capital firms.
• Finders and maps. A dealer locator for a welding equipment manufacturer, a rep locator for an HVAC manufacturer, a health center finder for a healthcare association, and a location finder with maps for a daycare group.
• Calculators and configurators. Return-on-investment calculators for industrial equipment, a custom pool cue builder for a cue maker and a moon reading tool for a publisher.
• Booking, ordering and requests. Appointment booking for medical practices, online ordering with a cart for a dumpster rental company, quote requests for manufacturers and suppliers, and ticketing and memberships for a theme park.
• Members and resources. Online courses with a member login, gated resource libraries, job boards, conference registration and investor relations pages with stock quotes and filings.

What makes these possible on a website is a content management system with an open door for developers. WordPress has the WordPress REST API, which its documentation describes as an interface for applications to interact with your WordPress site by exchanging data in JSON. A custom feature can read your content, store its own data and talk to other systems, while your team keeps editing pages in the editor they know. Our guide to content management systems explains what the CMS does and doesn’t do.

The trap is reaching for a plugin for each need. A plugin that does roughly what you want, with its own settings and its own update schedule, is fine for one feature. Five of them, stitched together, become the slow and fragile site that makes people ask for an app in the first place. Our guide to WordPress plugins covers how to tell a good one from a risky one.

When the website stops being enough

There are a few points where a custom feature on a website turns into a web app, whatever you call it:

• The rules get complicated. Pricing with exceptions, approvals that depend on who asked, or workflows with branches. A feature built to fit inside a page starts fighting the page.
• Every screen is personal. When almost nothing on the site is the same for two users, the page-based model is carrying nothing useful.
• Other systems depend on it. When your accounting, inventory or CRM software reads from the site and writes to it, the site needs the same care as those systems, with testing and someone on call.
• Load and speed. Hundreds of people using the same tool at once, each with their own data, is a different engineering problem from thousands reading the same page.
• Sensitive data. Health or financial records need accounts, permissions and logging designed on purpose, by people who do that for a living.

At that point we build in custom code. For us that means Next.js, with WordPress kept where it is good, which is the pages your marketing team edits. Our guide to Next.js and WordPress explains when each one fits.

What is different about building a web app

A website project starts with pages and content. A web app project starts with the work people need to do. Expect these steps to take more time than they would on a website, and plan for them:

• Mapping the work. Who uses it, what they do in what order, what they must see and what they must never see. Most of the cost of a web app is decided here, before any code.
• Designing the data. What a customer, an order or a claim is, what belongs to it and what happens when it changes. Getting this right early saves rebuilding later.
• Accounts and security. Sign-in, password resets, permissions and a record of who did what. The OWASP Top 10, a reference standard for the most critical web application security risks, is the list your developers should be building against.
• Connections to other systems. Each one needs its own design, testing and a plan for what happens when the other system is down.
• Testing. A page either shows or it doesn’t. An app has paths through it, and each one needs to be tried before real users find the broken one.
• Hosting and monitoring. An app needs a place to run, a database, backups and alerts, so someone knows before your customers do.
• Upkeep. Software has to be kept current, and a web app has more of it. Budget for developer time after launch, the way you would for any system your business runs on. Our website maintenance checklist covers the basics that apply to both.

Two things don’t change. The public pages still need to be found. Google’s guide to JavaScript SEO explains that it queues pages for rendering and runs their JavaScript later, when its resources allow, and that if the content isn’t visible in the rendered HTML, Google won’t be able to index it. Pages you want to rank should arrive as finished HTML. And the app still has to be fast. Google’s Core Web Vitals apply to app screens as much as to pages: the main content within 2.5 seconds, a response to each tap within 200 milliseconds, and a layout that doesn’t jump.

The middle path most businesses take

The most common answer to “website or web app” is both, kept separate on purpose. The public site stays a website your team edits, with the pages that explain what you do and bring in enquiries. The app lives behind a login, often at its own address such as a portal or app subdomain, with the same design so it feels like one place.

This keeps each side on the tools that suit it. Marketing pages stay cheap to change. The app gets the engineering it needs without dragging the public site along with it. When the app grows, the website doesn’t have to be rebuilt, and when the website is redesigned, the app keeps running.

Questions to settle before you ask for a quote

• What are the three things people most need to do on the site, in order?
• Who are the users, and do any of them need to sign in?
• What information is different for each user, and where does it live today?
• Which other systems does the site have to read from or write to?
• Does anything on the site change status over time, and who changes it?
• What has to be true for the site to be “down”? Who gets called?
• Which pages need to rank on Google, and which never will?
• Who will own the app after launch, and what is their budget for upkeep?
• Could the first version be a website with one custom feature, with the app later?

Bring the answers to any developer you talk to. Our guide to everything we need to get started lists what else a studio will ask for, and how to choose a web design company covers the questions to ask them back.

Questions we hear

Is a web app the same as a mobile app?

No. A web app runs in a browser on any device, and there is nothing to install. A mobile app is built for a phone’s operating system and distributed through an app store. Many businesses start with a web app, because one build reaches every device, and add a mobile app only when there is a reason a browser can’t serve.

Can a WordPress site be a web app?

Up to a point. Logins, portals, calculators, booking and ordering all work well on a WordPress site with a custom theme, and the examples above are all WordPress sites. When most of the site has to be personal, or the rules and integrations get complicated, custom code is the better foundation. Our guide to Next.js or WordPress goes into the trade-offs.

How long does a web app take to build?

Longer than a website with the same number of screens, because the time goes into mapping the work, designing the data and testing the paths through it. The surest way to shorten it is a small first version that does the most important job well.

How much does a web app cost?

It depends on what it needs to do, how many kinds of users it has and what it connects to. Quotes are free: configure your site or email us, and we send your quote by email.

Will a web app rank on Google?

Its public pages can, if they are built as pages Google can read without waiting for JavaScript. The screens behind a login won’t, and shouldn’t. Decide which pages need to be found and build those as a website, whatever the rest is.

Not sure which one you need?

Tell us what the site has to do and we’ll recommend the simplest build that does it. See our custom web development work, read about Next.js and WordPress, or configure your website and get a quote.