Softomate Solutions is a London-based software development studio helping UK businesses build digital products that actually fit their operations. One question comes up in almost every early conversation: should this be a website or a web application? The answer shapes your budget, your timeline, your hosting infrastructure, and whether your project succeeds or quietly frustrates everyone who uses it.
A website is a collection of pages that deliver content to visitors. A web application is a piece of software that runs in a browser, processes data, responds to user actions, and maintains state. The distinction sounds simple, but it has significant technical and commercial implications.
Websites are primarily stateless. Every page request returns HTML from a server (or a CDN edge node), the browser renders it, and that transaction is complete. The server does not remember who you are between requests unless a cookie is explicitly involved. A marketing brochure site, a blog, a portfolio, a news publication, an events calendar - these are websites. They deliver content efficiently and cheaply. A well-built static site can handle millions of visitors on a ยฃ10/month hosting plan because there is no server-side computation happening on each request.
Web applications are stateful. They remember who you are, track what you have done, process the data you submit, write to databases, trigger background jobs, send notifications, and surface personalised information on demand. A CRM, a customer portal, a booking system, an internal stock management tool, a SaaS platform, an expense approval workflow - these are web applications. They require persistent storage, authentication systems, server-side logic, and considerably more engineering.
The practical test is straightforward: if removing the user login would make the product meaningless, you are building a web application. If removing user login would leave a perfectly useful read-only resource, you have a website.
Websites deliver information to visitors without requiring them to identify themselves or take actions that change the underlying data. Common examples in the UK business context include:
None of these require a user account, persistent sessions, or complex server-side logic. They can be built as static HTML, hosted on a CDN, and served globally with sub-100ms load times. The engineering complexity is low, and the running cost is minimal.
Web applications are distinguished by their need to process, store, and personalise data for individual users. UK business examples include:
Each of these requires authentication, database persistence, session management, input validation, and often real-time features such as notifications or live data updates. If you are commissioning web application development from an agency, your provider needs to think carefully about architecture from day one, not retrofit complexity onto a simple website structure.
E-commerce is the clearest grey-area case. A Shopify storefront is simultaneously a website (product catalogue, editorial content, brand pages) and a web application (cart state, checkout process, order management, customer accounts, inventory). Most mature e-commerce platforms handle this duality with a hybrid architecture: static or server-rendered pages for discovery, and client-side application logic for the transactional layer.
Contact forms introduce minimal application behaviour into an otherwise static site - a POST request goes somewhere, an email fires, a row lands in a database. This does not make a brochure site a web application; it makes it a website with a form handler.
The inflection point comes when the behaviour the business needs can no longer be bolted onto a CMS without becoming a maintenance nightmare. If you are adding more plugins to WordPress than there are pages on your site, if you are writing custom PHP to do things the CMS was never designed for, or if your marketing team cannot edit the site without developer involvement because the logic is so tangled, you have drifted into web application territory through the wrong door. That is a more expensive problem to fix later than to address correctly at the start.
Real-time data is another inflection point. A website that shows stock prices, live event capacity, or driver location has crossed into web application territory the moment that data updates without a page refresh. Implementing WebSockets or server-sent events, managing connection state, and handling graceful degradation is application engineering, not web publishing.
Performance characteristics are fundamentally different between the two, and this matters for both user experience and search visibility. A static website served from a CDN edge network delivers HTML from a server physically close to the user. Cloudflare's global network has data centres in London, Manchester, Edinburgh, and across the UK, meaning a visitor in Leeds receives a cached HTML response from a nearby node in under 20 milliseconds. There is no database query, no server-side rendering, no session lookup.
A web application must perform computation on every meaningful request. That involves authenticating the user (checking a session token or JWT), querying a database (retrieving user-specific data), applying business logic (checking permissions, running calculations), and assembling a response. A well-engineered application with database connection pooling, query optimisation, Redis caching for hot data, and appropriate infrastructure can do this in under 100 milliseconds for most requests. A poorly engineered one can take three to ten seconds and frustrate every user who touches it.
The practical implication for UK businesses is that web applications require meaningful infrastructure investment and engineering discipline that websites do not. A website on shared hosting is fine. A web application on shared hosting is a disaster waiting for peak traffic to trigger.
Google's Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift) now influence search rankings. Web applications that render slowly due to client-side JavaScript waterfalls or slow API responses suffer in search as well as in conversion. This makes the choice of rendering strategy (server-side rendering, static generation, client-side rendering) a business decision as much as a technical one when the application has public-facing content that must rank.
The cost difference is significant and should shape every decision you make before commissioning work.
A well-built professional website - five to fifteen pages, a contact form, a CMS for editorial updates, responsive design, solid performance and SEO foundations - costs between ยฃ3,000 and ยฃ15,000 from a quality UK agency. Simpler sites done on a platform like Webflow cost less. Complex editorial sites with custom post types, multiple layouts, and integrations cost more. Timeline is typically four to twelve weeks.
Web applications start at a different baseline. A focused internal tool or a customer portal with authentication, a handful of core workflows, and basic reporting will typically cost ยฃ15,000 to ยฃ40,000 from a London development team. Customer-facing SaaS products with multi-tenant architecture, payment processing, and a polished UX start at ยฃ50,000 and commonly reach ยฃ150,000 to ยฃ200,000 for a serious v1. Timelines run from three months for a focused MVP to twelve or eighteen months for a complex product. London developer day rates for senior engineers run ยฃ500 to ยฃ900. Regional UK rates sit closer to ยฃ350 to ยฃ600 per day.
The reason web applications cost more is not arbitrary. Every feature that involves state introduces complexity: the data model must be designed, migrations must be managed, edge cases must be handled, security must be considered at every layer, and the system must behave correctly when concurrent users interact with shared resources. That engineering discipline takes time and expertise. If a proposal for a complex web application comes in at ยฃ8,000, that is a warning sign, not a bargain.
Websites typically deploy as static HTML generated by a framework like Next.js, Nuxt, Astro, or Eleventy, hosted on a CDN edge network such as Cloudflare Pages, Vercel, or Netlify. There is no application server processing requests in real time. Build pipelines regenerate the HTML when content changes. This architecture is extremely resilient, fast, and cheap to operate.
Web applications require a persistent backend. The choices here are meaningful and should align with your team's expertise and long-term maintenance plan:
Frontend frameworks for web applications are typically React, Vue, or Angular, often combined with a backend via a REST or GraphQL API. Next.js and Nuxt bridge the gap by offering server-side rendering for performance alongside the rich client-side interactivity a web application needs.
Databases for web applications almost always use PostgreSQL as the primary relational store. For applications with high read throughput, Redis handles caching and session storage. Applications with complex search requirements add Elasticsearch or Meilisearch. Document stores like MongoDB suit certain unstructured data patterns but are often overused for problems that relational models handle better.
Work through these questions in order:
Does the product need user accounts? If the answer is yes, you are building a web application. Full stop.
Does the product need to process, store, or retrieve data on behalf of individual users? Yes again means web application.
Does the product need to respond to user actions in ways that affect other users or the business's data? A booking system affects availability for other potential customers. An order changes stock levels. A support ticket creates a workflow. These are application behaviours.
Could the product work without a backend if you removed personalisation? If stripping authentication leaves a perfectly useful read-only resource, start with a website and add application features only when you have validated the need.
For early-stage businesses or new product ideas, consider starting with the simpler thing intentionally. Validate your market with a website and manual processes before investing in custom software. Many successful UK businesses operate with a simple marketing site and a spreadsheet far longer than they expect - and that is often the right call. Commissioning bespoke software development before you have validated your assumptions is an expensive way to learn what your customers actually want.
This transition is one of the most common and most poorly handled scenarios in UK digital projects. A business starts with a brochure site, adds a contact form, then a basic booking integration via a third-party embed, then a login area for existing clients, then a custom admin panel, and eventually finds itself running a business-critical operation on a WordPress installation held together with fifteen plugins and a prayer. This is not an unfair characterisation: it is the origin story of most problematic legacy systems we encounter during discovery.
The correct approach when a website needs to grow into a web application is to draw a clear architectural boundary and rebuild the application layer properly rather than continuing to bolt on functionality to an unsuitable foundation. This is not always the answer the business wants to hear, particularly when the existing site represents a recent investment. But the cost of rebuilding on a proper application framework after twelve months of accumulated workarounds is consistently lower than the cost of maintaining the hybrid and adding features that become progressively harder to implement correctly.
Practically, this means: keep the marketing website (it is working), build the application on a proper framework alongside it, and connect them via API or shared authentication. The two products serve different purposes and can evolve independently. This is how serious digital businesses operate - a marketing website optimised for acquisition alongside a product application optimised for retention and engagement.
Yes, but the cost of retrofitting application features onto a website architecture is usually higher than building correctly from the start. If you know your roadmap includes authentication, user data, or complex workflows within twelve months, begin with a proper application framework. The exception is adding a simple form handler or a third-party SaaS widget to an otherwise static site, which is low-cost and low-risk.
Consistently yes. A focused website can go from brief to launch in four to eight weeks. A web application with authentication, a data model, and three or four core workflows takes at minimum three months for a disciplined team, and six to twelve months is common for anything approaching a finished product. Rushed web applications accumulate technical debt that costs significantly more to fix than to avoid.
A PWA is a web application that is enhanced to behave like a native mobile application: it can work offline, send push notifications, be installed on a device home screen, and load with near-instant performance from a service worker cache. PWAs are web applications with additional capabilities. They are not websites. Building a PWA typically adds 20 to 40 per cent to development cost compared to a standard web application due to the service worker logic, offline state management, and cross-browser testing required.
Traditional server-rendered websites have an inherent SEO advantage because search engine crawlers receive complete HTML on the first request. Single-page web applications built with React or Vue can suffer if they rely on client-side rendering, because Googlebot must execute JavaScript to see content. This is solvable with server-side rendering (Next.js, Nuxt) or static site generation, but it adds complexity. If your web application has public-facing content that must rank, insist on server-side rendering from your development team.
Warning signs include: users requesting accounts or logins; manual processes happening offline that could be automated (order processing via email, booking via phone call); data living in spreadsheets that multiple people need to access; staff spending significant time on tasks that software could handle; or the business's core workflow being invisible to the digital product. When manual workarounds cost more in staff time than the software would cost to build, the crossover point has arrived.
More from the blog
Let us help
Talk to our London-based team about how we can build the AI software, automation, or bespoke development tailored to your needs.
Softomate Solutions Limited
Deen Dayal Yadav
Online
