The Most Expensive Misunderstanding in Our Industry
A client asks for a website. Three weeks in, it turns out they need customer logins, a booking calendar, and a way for staff to manage availability. That's not a website — it's software with a homepage attached, and the budget, timeline and team are now all wrong.
It happens constantly, and it's rarely anyone's fault. "Website" is the word people have for anything that lives at a web address. So here is the distinction in plain terms, before it costs you a quarter.
The One Question That Separates Them
Does a visitor create or change data that has to be there when they come back?
If no, it's a website. Every visitor sees roughly the same thing. A contact form that sends an email doesn't change this — the email leaves, nothing is stored, nobody logs in.
If yes, it's a web application. Accounts, saved state, permissions, records that must stay accurate. That means a database, authentication, a way to recover a forgotten password, an admin view, and a real answer to what happens when two people edit the same thing at once.
The gap between the two is not a matter of degree. A brochure site is content work; an application is software engineering, with testing, data modelling and ongoing operational responsibility attached.
What Each One Realistically Involves
A website is measured in weeks. The work is largely design, content and performance: making it clear, fast, findable and persuasive. The main risk to the timeline is content — it's almost always the client's copy and photography that arrive late, not the build.
A web application is measured in months, and roughly half the effort sits in places nobody demos: user management, permissions, error handling, data migration, admin tooling, and the tedious edge cases that decide whether the thing is trustworthy. When an app quote looks surprisingly high next to a website quote, this is usually why.
A mobile app — meaning something in the App Store — is a further step again: two platforms, store review processes, release cycles, and users who may be running a version from eighteen months ago. Worth it when you genuinely need push notifications, offline use, or device hardware. Not worth it because an app feels more serious than a website.
When a Website Is Quietly Enough
Plenty of businesses describe an application and need a website with two integrations. Before committing to custom software, check whether an existing tool already solves it:
- Appointments – a scheduling tool embedded in your site handles reminders, calendars and payment, usually for the price of a coffee per month.
- Selling things – a hosted store covers payments, tax and shipping rules, all of which are genuinely difficult to build well.
- Gated content or memberships – mature platforms exist; building your own login system is a real ongoing security responsibility.
- Internal processes – a spreadsheet plus an automation tool solves more business problems than anyone in our industry likes to admit.
Custom software earns its cost when the process is your business — when the workflow is genuinely unusual, when integration between systems is the whole point, or when you're selling access to the tool itself. It rarely earns its cost as a slightly nicer version of something you could subscribe to.
If You Do Need an App, Scope It Honestly
The first version should do one thing end to end for one type of user. Not a reduced version of everything — a complete version of the single most important journey. If a customer can sign up, book, pay and receive confirmation, you have something real to learn from. Six half-finished features teach you nothing.
Two things worth deciding early, because they're expensive to retrofit: who the different kinds of user are and what each may see, and what happens to the data if you stop using the system. A clear answer to both at the start prevents most of the painful conversations later.
A Shortcut for the Brief
Write one sentence: "A [type of user] uses this to [do something] so that [outcome]." If the sentence works without anyone logging in, brief a website. If it doesn't, you're commissioning software — and the brief needs to say so, so that everyone quotes the same thing.
Getting this right in the first conversation is the cheapest project decision you will make.
Not sure which side of the line your idea falls on? Tell us what you're trying to do — we'll tell you honestly, including when the answer is a simpler build than you expected.