The distinction that changes the price by 5×
Briefs frequently say “a website with a members' area where they can upload documents and track progress”. That is not a website with an area. That is an application, and pricing it as a website is how projects go badly wrong for both sides.
The clean test: does a visitor consume, or do they do? Consuming is a website. Doing — with an account, saved state and rules about who may do what — is an application.
What makes applications cost more
- State. Something must be remembered between visits, correctly, forever.
- Identity and permissions. Who can see and do what, including the awkward cases.
- Business rules, which are always more numerous than the first conversation suggests.
- Failure handling. A page that fails to load is annoying; a payment that half-completes is a serious problem.
- Testing. Applications need real test coverage because regressions are invisible until a user finds them.
None of that is visible in a design mock-up, which is why applications quoted from designs are routinely underestimated.
Signals your website is actually an application
- Users log in and see different things
- Data is saved and edited over time
- Money moves, or a subscription exists
- Multiple roles with different permissions
- It integrates with another system in a way that has to be reliable
- Somewhere in the brief is the phrase “and then it should automatically…”
Two or more of these and you should be budgeting for an application.
Realistic numbers
| Type | Typical range | Timeline |
|---|---|---|
| Brochure site | £3,000–£8,000 | 4–8 weeks |
| Marketing site with CMS | £8,000–£25,000 | 8–14 weeks |
| Simple application (accounts, one workflow) | £25,000–£60,000 | 3–5 months |
| Multi-role application with integrations | £60,000–£150,000 | 5–9 months |
| Platform with billing and third-party APIs | £150,000+ | 9 months+ |
How to reduce application cost without gutting it
Cut roles before you cut features. Each additional user role multiplies the permission matrix and the testing. Launching with one role and adding the second later is often 30% cheaper than launching with both.
The other reliable saving: use something off the shelf for authentication, payments and file storage. Bespoke versions of solved problems are where budgets vanish with nothing to show.
The maintenance difference nobody mentions
A brochure site can sit for two years needing only updates. An application cannot: dependencies age, security patches matter more because there is data behind a login, and users generate feature requests by using it.
Budget 15–25% of build cost annually for an application. If that is not affordable, the honest conclusion is that the application is not affordable — better to know before the build than eighteen months in.