Every project starts with the same question, phrased a dozen different ways: "we need a website." But a website, an online store and a web app are three different products, built to do different jobs. Picking the wrong one doesn't just waste budget — it usually means rebuilding from scratch a year later.
Here's a practical way to tell them apart before you brief anyone.
Start with what the visitor needs to do, not what you want to show
Most website briefs start with pages: home, about, services, contact. That's a reasonable checklist for a brochure/marketing site — its job is to inform and build trust, then hand the visitor off to a phone call, an email or a contact form.
The moment your project involves any of the following, you've stepped outside a brochure site: - Visitors need to browse a catalog and pay online - Visitors need to log in and see something different from the next visitor - Data needs to be entered, stored and acted on (bookings, orders, applications) - The business runs a repeatable internal process that a form and a spreadsheet can't handle anymore
Ecommerce: when the job is "sell products online"
An ecommerce site is a marketing site with a transaction layer bolted on: product pages, cart, checkout, payment, order confirmation. It's still mostly public-facing — the same catalog for every visitor — but now money changes hands.
The decision that matters most here isn't design, it's the backend: how many products, how often they change, who manages inventory, and whether you need integrations (accounting software, shipping carriers, marketplaces). A 20-product catalog that changes twice a year and a 2,000-SKU store with daily stock updates are not the same project, even if they look similar to a visitor.
WebApp: when visitors stop being visitors and become users
A web app is what you need when people log in and the experience becomes personal: a dashboard, a client portal, a booking system, an internal tool for staff. The content isn't the same for everyone — it depends on who's logged in and what they've done.
This is also where "just add a feature" stops being a small ask. Authentication, permissions, data validation and edge cases add real engineering time that a brochure site never touches. If your project description includes "users can..." more than once, you're describing a web app, not a website.
Social media: not a fourth category, a companion to all three
Social channels don't replace any of the above — they're where you drive traffic *to* the site, ecommerce store or app. A common and expensive mistake is investing heavily in social content while the destination it points to (an outdated site, a clunky checkout) undoes all that work at the last step.
A quick test
Ask three questions about your project: 1. Does every visitor see the same thing? → brochure site. 2. Does money change hands online? → ecommerce. 3. Do visitors log in and get a personalized experience? → web app.
If the honest answer touches more than one, that's fine — plenty of real projects are a brochure site *plus* a small booking tool, or an ecommerce store *plus* a client area. The point isn't to pick a label, it's to scope the right thing from day one instead of discovering the real requirements halfway through a build.
Not sure which one fits? Get in touch and we'll help you scope it before any code gets written, or browse what each option actually includes on our services page.