Website or Web App: Which Does Your Business Need?

Plenty of software projects go wrong at the first meeting, when everyone agrees to build "a site" without agreeing on which kind. A website and a web app are both things you open in a browser, and that is roughly where the similarity ends. They are scoped differently, built differently, cost differently and succeed or fail by different measures.

Getting this wrong is expensive in a specific way: you budget for one and discover halfway through that you are building the other.

The distinction that matters

A website publishes. Its content is largely the same for everyone, it is read far more often than it is written to, and its job is to be found, understood and acted on. Success is measured in traffic, rankings and enquiries.

A web app does work. Users log in, see data specific to them, and change something — a booking, a record, an order, a document. Its job is to make a workflow faster or possible at all. Success is measured in whether people can complete the task, and whether the data stays correct when they do.

The clean test: does a user log in and change data that persists and matters to someone else? If yes, you are building an application, whatever anyone called it in the kick-off.

Why the difference costs money

Almost all of the hard parts of an app come from that one difference.

• Accounts and permissions. Who can see what, who can edit what, what happens when someone leaves. None of this exists on a brochure site and all of it takes real time.
• State that has to stay correct. Two users editing the same record, a failed payment halfway through, a browser closed mid-form. A website has no equivalent problem.
• Edge cases multiply. Every input is a place a user can do something unexpected, and every one needs a defined behaviour.
• Testing is different work. You are testing that a process produces the right result under bad conditions, not that a page looks right.
• It never really ships. A marketing site can sit for a year. An app people depend on needs monitoring, fixes and iteration, which is why maintenance and debugging is a line item rather than an afterthought.

This is why "it is just a few screens" estimates go wrong. The screens are not the work. The rules behind them are.

Where websites are underestimated instead

The mistake runs both ways. Teams that think of a marketing site as trivial produce something slow, unclear and invisible to search — and then wonder why the traffic budget is not converting.

A site that has to rank and convert is its own discipline: fast enough not to lose people before it renders, structured so search engines can read it, and written so a visitor knows within seconds whether they are in the right place. That is web development in service of a commercial outcome, and it is closer to SEO and conversion work than to software engineering. Which channel should then pay for the traffic is a separate question, covered in SEO or paid ads.

Most businesses need both, connected

The realistic shape for most companies is a public site that markets and a private application that serves. A brokerage has a marketing site and a client portal. A clinic has a website and a booking system. A retailer has a storefront and an admin.

The failure mode is treating them as one project with one set of decisions. They have different audiences, different release rhythms and often different technology. What they should share is a single source of truth — the enquiry from the website should arrive in the same system the app writes to, rather than in an inbox somebody re-types from.

Building them as two connected products, rather than one blurred one, keeps each simple and lets the marketing site change weekly without anyone fearing the application will break.

The middle ground

Not everything is one or the other. A pricing calculator on a marketing site is app-like but stateless. A customer portal with three read-only screens is an app in structure but small in scope. The useful question is not which label fits, but how much of this involves saving data that someone will rely on later — because that is what carries the cost.

When the answer is "a little", build it as part of the site. When it is "the whole point", scope it as custom software and resource it accordingly.

And the mobile question

Web app or native app is a separate decision, and it comes later than people think. A responsive web app reaches everyone immediately with nothing to install. A native mobile app earns its place when you need push notifications, offline use, camera or location, or when usage is frequent enough that an icon on the home screen changes behaviour.

Deciding this before you know how people actually use the product is guessing. Most businesses are better served shipping the web version, watching what people do, and building native for the workflows that genuinely need it.

Questions to settle before scoping

1. Do users log in? If yes, it is an app.
2. Does the content differ per user, or is it the same for everyone?
3. Does anything a user does need to still be true tomorrow?
4. Who is harmed if the data is wrong, and how badly?
5. Does this need to be found in search, or is it reached by people who already know about it?
6. How often will it change after launch?

Answer those honestly and the budget stops being a negotiation and starts being an estimate.

Frequently asked questions

Can one team build both?

Yes, and there are advantages to it — the enquiry path from site to system stays joined up. Just scope and schedule them separately, because they move at different speeds.

Is a web app cheaper than a native app?

Usually to start, because one build reaches every device and there is no app store process. Whether it stays cheaper depends on how much you end up fighting the browser for capabilities you actually needed natively.

We were quoted wildly different prices. Why?

Frequently because the quotes are for different things: one priced the screens, the other priced the rules, permissions and edge cases behind them. Ask each to state what happens when two users edit the same record, and the gap usually explains itself.

Should the marketing site and the app share a design system?

Share the brand — colours, type, logo — so it feels like one company. Do not force identical components. Marketing pages optimise for persuasion, application screens for density and clarity.

What if we are not sure which we need?

Write down the three things a user must be able to do. If all three are "find out about", it is a website. If any is "submit", "manage" or "track", it is an app.

If you want help scoping either, see how we approach IT, web and digital services or talk to us about the specific build.