Start with the main business decisions
Website vs web application
The distinction between a website and a web application is not about how something looks, but about what it does. A website presents information. A web application processes it. If a visitor arrives, reads pages, follows links and leaves, they have used a website. If they log in, submit data, trigger workflows and receive different results depending on their role and inputs, they have used a web application.
This difference matters because it changes what you are buying, how long it takes to build, who needs to be involved and what you must manage afterwards. A brochure site for a professional services firm is a website. The system that firm uses to manage client matters, record time, generate invoices and give clients access to their documents is a web application. Both live in a browser. Only one has business logic, user accounts, permissions and data persistence at its core.
The confusion usually starts when a business needs something that sits between the two: a site with a contact form, a booking page or a simple calculator. These are website features, not applications. The line is crossed when the system must store data per user, enforce rules about who can see or change what, and support repeatable processes rather than one-off submissions.
What makes a web application different from a website
Several structural differences separate web applications from websites, and each one carries practical implications for the business commissioning the work.
User accounts and authentication. A web application needs to know who is using it. That means login systems, password management, session handling and usually some form of role assignment. A website may have none of these. Once you introduce accounts, you also introduce the need to handle forgotten passwords, account lockouts and potentially single sign-on integration with other business systems.
Permissions and access control. Not every user should see or do the same things. A web application enforces rules about what each role can access. An administrator might configure system settings, a manager might approve workflows and a front-line worker might only submit and view their own records. Designing these rules correctly requires mapping real business roles to system permissions before development starts.
Data persistence and state. A website serves the same content to any visitor at a given URL. A web application serves different content depending on who is logged in, what they have done previously and what state their work is in. An order in progress, a partially completed form or a draft document are all examples of state that the system must track and preserve.
Business logic and workflows. Web applications enforce rules. An invoice cannot be marked as paid until a payment is recorded. A document cannot progress to the next approval stage until the current reviewer has acted. These are not display decisions; they are process rules that must be defined, tested and maintained.
Integrations with other systems. Web applications rarely exist in isolation. They connect to accounting software, payment processors, email services, CRMs or internal databases. Each integration introduces dependencies, data-format requirements and points of failure that a standalone website does not have.
When a business needs a web application instead of a website
The need for a web application usually becomes apparent through specific operational problems rather than a general desire for new technology. Recognising these signals early prevents the common mistake of trying to stretch a website or a spreadsheet beyond what it was designed to do.
Multiple people need controlled access to the same data. When three or more colleagues are emailing spreadsheets to each other, overwriting each other's changes or maintaining separate copies that gradually diverge, the underlying problem is the absence of a shared system with proper access controls. A website cannot solve this. A web application can.
Processes must be enforced, not just documented. A procedure written in a policy document relies on individuals following it correctly every time. A web application can make it difficult or impossible to skip steps: a claim cannot be submitted without the required attachments, an approval cannot be bypassed, a compliance check cannot be left blank. When the cost of human error is material, enforcement through software becomes a business requirement.
External users need self-service access to specific functions. If clients, partners or suppliers regularly phone or email your team to check order status, download documents or submit information, building a portal that gives them controlled access can reduce internal workload and improve response times. This is a web application, even if the interface is simple.
Data must flow between systems without manual re-entry. When a sale in one system must create a record in another, or when stock levels in a warehouse system must update a customer-facing order page, manual copying becomes a bottleneck and a source of errors. Web applications can automate these flows through integrations, but only if they are designed with those connections in mind from the start.
A clear warning sign that a business is heading for trouble is the phrase "we just need a simple website that also does X." If X involves user accounts, workflow rules, role-based permissions or system integrations, it is not a simple website. Framing it as one leads to underestimated budgets, mismatched supplier expectations and projects that stall when the gap between website thinking and application requirements becomes unavoidable.
Types of web application: Internal tools, portals and SaaS platforms
Web applications serve different purposes within a business, and the type affects everything from the design approach to the commercial model.
Internal tools
Internal tools are web applications built for a business's own staff. They replace spreadsheets, manual processes or disjointed collections of software that do not talk to each other. Common examples include admin panels for managing customer records, workflow systems for processing applications or claims, and reporting dashboards that pull data from multiple sources.
The defining characteristic of an internal tool is that the users are known, trained and bound by employment contracts. This means the interface does not need to sell itself or onboard strangers. It needs to be efficient for people who use it daily. Usability still matters, but the priority is speed, accuracy and fitting the specific process rather than visual polish for a public audience.
Portals
Portals give external users controlled access to part of a business's systems. A customer portal might allow clients to view their order history, download invoices or submit support requests. A partner portal might let suppliers see purchase orders and update delivery status. A recruitment portal might let candidates track their application progress.
Portals sit between internal and public. The users are not employees, so the interface must be intuitive without training. But the users are also not anonymous visitors; they have accounts, specific permissions and a defined relationship with the business. Security is critical because portal users should only ever see their own data, never another customer's or another tenant's records.
SaaS platforms
A SaaS platform is a web application that the business sells as a product to other businesses or consumers. Users sign up, pay a subscription and gain access to the software over the internet. The business operating the SaaS platform is responsible for hosting, updates, support and uptime.
SaaS introduces complexities that internal tools and portals do not. Multi-tenancy, where each customer's data must be kept strictly separate, is a fundamental architectural requirement. Subscription billing, usage-based pricing and tiered feature sets add commercial logic to the application. Onboarding flows must work without human intervention, because new customers arrive at any time. Scaling becomes a live concern rather than a theoretical one, because the business model depends on adding customers without adding proportional cost.
Progressive web apps vs traditional web applications
Progressive Web Apps, or PWAs, are web applications built with specific technical capabilities that allow them to behave more like native mobile apps. They can work offline or with poor connectivity, send push notifications, be added to a device's home screen and access certain device features such as the camera or geolocation.
The practical appeal for a business is that a PWA avoids the need to develop, maintain and distribute separate iOS and Android applications while still offering a mobile-optimised experience. For users, the benefit is not having to visit an app store; they simply use their browser and optionally "install" the app to their device.
However, PWAs are not a universal replacement for traditional web applications or native mobile apps. Offline capability is useful for field workers who lose connectivity, but most internal business tools and portals require a live connection to the server because the data they display and change must be current. Push notifications are valuable for time-sensitive updates, but many business applications do not need them. Device-feature access is broader than it was, but still more limited than a native app for certain use cases.
The decision between a PWA and a traditional web application should follow from what users actually need to do, not from the desire to use a newer technology. If the core use case involves a logged-in user working with live data on a desktop or laptop browser, a traditional web application is usually the simpler and more appropriate choice. If the core use case involves mobile users who need offline access or push notifications, a PWA warrants serious consideration.
Single-page applications vs multi-page web applications
This distinction concerns how the application behaves in the browser, and it has real consequences for performance, development approach and user experience.
A multi-page web application works the way the web was originally designed: each action loads a new page from the server. Clicking "save" on a form might submit the data, process it on the server and return a completely new HTML page showing the updated record. Navigation between sections means full page reloads. This approach is straightforward, works reliably with search engines and assistive technology, and does not require complex client-side code.
A single-page application, or SPA, loads a single HTML page initially and then handles all subsequent interaction within the browser using JavaScript. When a user navigates to a different section or submits a form, the application updates only the parts of the screen that need to change, fetching or sending data in the background. The result can feel faster and more responsive because full page reloads are eliminated.
The trade-offs matter for business applications. SPAs introduce more complexity on the front end, which can increase development time and the skill requirements of the team. They can cause problems with browser history, bookmarking and accessibility if not implemented carefully. Initial load times can be slower because the browser must download more JavaScript before anything useful appears. For internal tools where users are on fast connections and value reliability over visual smoothness, a multi-page approach is often the pragmatic choice. For customer-facing portals or SaaS products where perceived speed and interactivity are competitive advantages, an SPA may justify the additional complexity.
The right architecture depends on the users, their devices, their connectivity and what the application needs to do. It is a decision best made during planning with input from both the business and the technical team, rather than a default preference applied to every project.
Web applications and the UK regulatory landscape
Web applications that process personal data, handle payments or provide services to the public fall within several regulatory frameworks that a business must consider from the outset. Treating compliance as an afterthought is a common and costly mistake.
Data protection. Where a web application processes personal data, the organisation should assess its current obligations under UK data-protection law, including the UK GDPR and the Data Protection Act 2018, against the specific roles, data and processing involved. This affects how data is collected, stored, shared and deleted. It requires a lawful basis for processing, transparency through privacy notices and the ability for individuals to exercise their rights, including access, correction and erasure. The design of the application must support these requirements, not just the privacy policy text.
Accessibility. For services within scope, the Equality Act 2010 can create duties to make reasonable adjustments for disabled people. The practical requirements should be checked against the service, its users and current guidance. For web applications, this means considering how users with visual impairments, motor difficulties or cognitive disabilities interact with the system. Public-facing portals and SaaS products require particular attention, while internal tools may also need accessibility adjustments in the employment context. Accessibility is best addressed during design and development, not retrofitted after launch.
Industry-specific requirements. Depending on the sector, additional regulations may apply. Financial services, healthcare, legal services and education each have their own rules about data handling, record-keeping and system controls. A web application built for one of these sectors must reflect those requirements in its design, not just in its operational procedures.
Contracts and liability. The contract between a business and its web-application supplier should address who is responsible for compliance, what happens if the application does not meet regulatory requirements and how liability is allocated. These are legal matters that require current specialist review, not assumptions based on standard terms.
Regulatory requirements should be identified during the earliest stages of defining what the application needs to do. They influence data architecture, user-interface design, hosting choices and the documentation the application must produce. Leaving them until testing or launch almost always results in rework, delay and increased cost.