# Website or web app? How to tell what you actually need

> Most projects start with the wrong word. A plain way to tell whether you need a website, a web application, or a website now and an app later.

By Odd Birds Studio · 27 Oct 2026 · Planning · 3 min read

“We need an app” and “we need a website” are often said about the same project. The words matter less than what people will do once they arrive, and getting that right early decides the budget, the timeline and the team you need.

## The short version

A website mostly tells. A web application mostly does. A website explains who you are, what you offer and how to reach you; most visitors read, compare and leave with an enquiry. A web application lets people sign in, enter data, change things and come back to find them changed.

**Website**

- Visitors read, compare and enquire
- Content changes weekly or monthly
- Most pages look the same for everyone
- Success means enquiries, calls and trust
- Usually a smaller, well-bounded scope

**Web application**

- Users sign in and get work done
- Data changes every minute
- Every user sees their own view
- Success means tasks completed and time saved
- Larger scope that keeps growing after launch

## Five questions that settle it

Answer these honestly. Each “yes” pushes the project toward an application.

### Website or web app?

Answer yes or no:

1. Will people need to sign in to their own account?
2. Will users create or edit things — orders, bookings, records — and expect to find them later?
3. Do different people need different permissions, such as staff, admins and customers?
4. Does it need to talk to other systems, like payments, inventory or a CRM?
5. Will people use it every week as part of their work, rather than visit once?

- **0–1 “yes”**: A website is enough. Your visitors mostly need to understand you and get in touch. Put the budget into clear content, speed and a strong enquiry path.
- **2–3 “yes”**: A website now, an app later. Start with a solid website and build the one interactive piece you need — a booking flow, a calculator, a members area — as its own small module.
- **4–5 “yes”**: You are building a web application. Plan for accounts, permissions, data and testing from day one. Scoping the first release carefully matters more than the visual polish.

## The middle ground is real

Plenty of good projects sit in between: a marketing website with one interactive part, such as a booking form, a quote calculator or a members-only page. You do not need a full application to get one useful feature. Build the website properly, then add the interactive piece as its own small, well-defined module.

> **A quick test**
>
> Describe the project without using the words “website” or “app”. If the description is mostly nouns — pages, services, team — it is a website. If it is mostly verbs — book, approve, track, assign — it is an application.

## Why the label changes the plan

- Scope: an application needs accounts, permissions, data models and edge cases a website never meets.
- Design: websites are designed page by page; applications are designed flow by flow.
- Testing: an application has to keep working when real people enter real, messy data.
- Upkeep: a website can sit quietly for months; an application needs someone looking after it.

> Name the thing correctly early and fewer surprises turn up in the quote.

## What it costs to pick the wrong one

Choose a website when you needed an application and the cracks show quickly: staff copy data between spreadsheets, customers email for things they expected to do themselves, and every new requirement becomes a workaround bolted onto a content site.

Choose an application when a website would do and the cost is quieter: you pay for accounts, permissions and infrastructure nobody uses, launch later than you needed to, and maintain more than the business requires.

### Signs you have outgrown a website

- The team re-types the same information into several places.
- Customers keep asking for things they could do themselves — check a status, change a booking, download a document.
- Plugins are being stacked onto a content system to make it behave like software.
- A spreadsheet somewhere has quietly become the real system.

## How to start either one well

For a website, start with content: what each visitor needs to understand, and what you want them to do next. Design and technology follow from that, not the other way round.

For an application, start with one workflow from beginning to end — a single order, a single booking, a single approval — and make that excellent before adding the next. A narrow first release that people actually use beats a broad one they merely tolerate.

Neither is better than the other. If you are still unsure, that is normal — it is usually the first thing worth working through in a discovery conversation.