"We need a website" is the brief about half the time, and about half of those briefs describe something else entirely.
The distinction matters because the three things differ in cost, timeline and the kind of risk they carry. Getting the category right before you ask for quotes is the cheapest decision in the whole project.
The short definition of each
A website presents. Pages, mostly stable, the same for everyone. Its job is to be found, to explain, and to produce an enquiry.
A web application does work. People sign in. Data changes. There are roles, permissions, states and rules. Its job is to replace or improve a process.
A SaaS product is an application that strangers pay for. Everything above, plus tenancy, subscriptions, onboarding, support and the expectation that it keeps running without you in the room.
Four questions that decide it
- Does anyone log in? No — website. Yes — application, at least.
- Does the same screen show different things to different people? That is permissions, and permissions mean an application.
- Is the software the product, or does it support the product? If customers outside your company pay for access, you are building SaaS.
- What breaks if it goes down at 2am? A website being down is embarrassing. An application being down stops work. A SaaS product being down costs you customers — and that difference is an ongoing operational cost, not a build cost.
What each actually involves
| Website | Web application | SaaS product | |
|---|---|---|---|
| Typical first version | 1–4 weeks | 4–8 weeks | 8 weeks upwards, in phases |
| Core concerns | Content, speed, search | Data model, permissions, workflow | Tenancy, billing, onboarding, support |
| Biggest risk | Nobody finds it | It solves the wrong process | It ships without a paying customer in sight |
| Ongoing cost | Hosting, small changes | Hosting, support, iteration | All of that, plus support and uptime |
The mistakes that cost the most
Building an application when a form would do. A surprising share of "portals" are a spreadsheet, an email and a PDF away from being solved. We will say so when that is the case.
Building a website when the process is the problem. The opposite error. A prettier brochure does not fix a business where three people are re-keying the same order.
Treating SaaS as an application with a payment page. Billing is the easy part. Tenancy, entitlements, trials, failed payments, support access and data isolation are the parts that are expensive to retrofit — which is why they get a design phase rather than a default.
Skipping the search layer entirely. Products get found the same way everything else does. If nobody can find the page that sells it, the engineering underneath is irrelevant — start here.
A practical sequence
For most businesses the right order is: a fast site that can be found, then the smallest application that removes the worst manual process, then — only if people outside the company want it — the product version of that application.
Each step funds the next, and each one is scoped so you can stop after it without having wasted the last.
How we scope it
We start from the job being done badly today, not from a feature list, and write down the phases with a price against each. If the answer is "this is a website, not an application", you get that answer before you get an invoice.
Software development covers applications, SaaS development covers products, and web development covers the site in front of both. Tell us what you are building and we will tell you which one it is.
Frequently asked questions
- What is the difference between a website and a web application?
- A website presents information; a web application does work. If people sign in, data changes, permissions matter, or a process runs through it, you are describing an application — regardless of whether it lives at the same domain as your marketing pages.
- When does an internal tool become a SaaS product?
- When people outside your company pay to use their own isolated copy. That adds tenancy, billing, onboarding, support and a support surface, which is why the same feature set costs meaningfully more as a product than as an internal tool.
- Can we start with a website and add an application later?
- Yes, and it is often the right sequence. The decisions that make it painless are architectural — where data lives, how authentication works, whether the marketing site and the product share a codebase — and they are worth making before the first build, not during the second.
- How much does each one cost?
- Our published starting points are from £350 for a single page, £650 for a full site with the search foundation, £950 for an application module, and £1,200 for a SaaS first release. Larger products are quoted against a written scope.
- software development
- saas
- product
