Web Applications

Start with the main business decisions

Understanding web applications

Website vs web application

A website presents information. A web application processes it. That distinction sounds simple, but it is where most confusion starts when a business begins scoping a project. A corporate brochure site, a product catalogue, even a blog with a comments form — these are websites. The visitor reads, navigates and occasionally submits a contact form. The server's job is to return the right page.

A web application has logic, state and rules. Users log in, see different data depending on their role, submit records that change the system's state, trigger workflows and generate outputs. A CRM, a customer portal, an internal approval tool — these are web applications. The server does not just serve pages; it enforces business rules, manages data relationships and coordinates between users.

The practical consequence of mixing the two up is a brief that under-specifies the work. A business asks for "a website with a login area" when what it actually needs is an application with role-based access, data validation, audit trails and integrations. The resulting quote either misses the real scope or, worse, the supplier builds something that looks right but cannot handle the operational demands.

When a business needs a web application instead of a website

Several clear signals indicate a web application rather than a website is the right tool. If different users need to see different data or perform different actions based on who they are, that is an application. If the system needs to store, update and retrieve structured records over time — orders, cases, compliance records, client files — that is an application. If processes need to move through defined stages with approvals, notifications or status changes, that is an application. If the output of one action becomes the input for another — a submitted form creates a task, which generates an email, which updates a dashboard — that is an application.

If the need is primarily to publish content, establish credibility or explain what the business does, a website is the correct starting point. Marketing websites belong to a different category of project and are planned, estimated and built on different assumptions.

Types of web application: Internal tools, portals and SaaS platforms

Within the broad category of web applications, three types recur in UK business contexts. Internal tools are systems used by a company's own staff — admin panels, workflow managers, reporting dashboards, stock-control systems. The user group is known, relatively small and governed by employment contracts and internal policies. Security requirements still apply, but the threat model is different from a public-facing system.

Customer and partner portals expose selected functionality to people outside the organisation. A client portal might let customers view their invoices, upload documents, track case progress or submit requests. The user group is larger, less predictable and not bound by internal policies, which changes the access-control and data-privacy considerations.

SaaS platforms are web applications delivered as a commercial product to multiple subscribing organisations. They introduce additional complexity around multi-tenancy, subscription management and onboarding — subjects covered separately in the SaaS Development section of this guide.

Web applications and the UK regulatory landscape

Where a web application processes personal data in a context subject to UK data-protection law, the organisation should assess the applicable UK GDPR and Data Protection Act 2018 duties against its role, users, data and processing. That means lawful bases for processing, data-minimisation principles, subject-access rights and, where relevant, Data Protection Impact Assessments are not afterthoughts — they shape how the application is designed from the start. The technical choices around data storage, retention, access controls and export capability all have regulatory implications.

Accessibility is another area where regulation meets technical design. For services within scope, the Equality Act 2010 can create duties to make reasonable adjustments. The practical requirements should be checked against the service, its users and current guidance. For web applications, that translates into considerations around screen-reader compatibility, keyboard navigation, colour contrast and content structure. These are not cosmetic additions; they are architectural decisions that are far cheaper to build in than to retrofit.

Specific sectors — financial services, healthcare, legal — bring additional regulatory frameworks. The right approach is to identify the applicable requirements early in planning and treat compliance as a functional requirement, not a separate workstream bolted on at the end. Current specialist legal review is essential; this guide explains what to plan for, not what your obligations are.

Planning a web application

What should be included in a web-app specification

A specification exists so that two separate parties — the business commissioning the work and the team building it — can agree on what will be delivered, how it will behave and what "done" looks like. Vague specifications produce vague outcomes and disputed invoices.

A practical web-app specification covers: the problem the application solves and for whom; the core processes it must support, step by step, including the exceptions and edge cases that usually cause the most trouble; the user roles and what each role is permitted to see and do; the data the system will hold, where it comes from, how it relates and how long it is kept; the integrations with other systems — what data flows in, what flows out and in what format; the non-functional requirements such as expected user volumes, response times, browser support and availability targets; and the acceptance criteria that will be used to confirm each piece of work is complete.

The specification does not need to dictate technical implementation — that is the supplier's domain — but it does need to be specific enough that a competent team could build the right thing without guessing.

How to define user roles for a web application

Roles define what a user can see and do. Getting them wrong creates either security gaps, where people access data or actions they should not, or operational friction, where legitimate users cannot do their jobs without requesting manual overrides.

The starting point is not the technology but the business structure. Who uses the system? What are their job functions? What data do they need, and what actions must they perform? A customer portal might have roles for end users, account managers and administrators. An internal tool might separate data-entry clerks, team leaders, compliance officers and system administrators. Each role needs a clear, written definition of its permissions — read, create, update, delete, approve, export — at the level of specific data types and screens.

A common mistake is defining roles at launch and never revisiting them. As the business evolves, people end up sharing logins, being granted excessive permissions as a workaround, or creating shadow processes outside the system because the role model no longer fits. Planning should include a mechanism for reviewing and adjusting roles over time.

How to map workflows and processes before building

Building a web application without mapping the underlying processes is like commissioning a factory layout without understanding the production line. The result may look plausible but will not work efficiently.

Process mapping for a web application means documenting each workflow the system must support: what triggers it, what steps it passes through, who acts at each step, what decisions are made, what data is created or changed, what happens when something goes wrong and what the end state looks like. This should cover the happy path — where everything proceeds normally — and the exception paths, which are where most design effort is actually needed.

The output does not need to be a formal diagramming standard. Flowcharts, numbered step lists, even structured text in a document are all acceptable. What matters is that every person involved in the project can read it and agree on what the process is. Ambiguity at this stage becomes change requests and delays later.

Functional vs non-functional requirements for web apps

Functional requirements describe what the system does: a user can submit an expense claim, an admin can approve it, the system sends a notification. Non-functional requirements describe how the system behaves: it must respond within two seconds, it must be available 99.5% of working hours, it must support 50 concurrent users without degradation, it must encrypt data at rest and in transit.

Non-functional requirements are frequently omitted from briefs because they feel abstract. But they directly affect architecture, hosting costs, testing effort and the choice of technology. A system built for ten internal users will be designed differently from one that must serve a thousand external customers, even if the functional requirements are similar.

The practical step is to state non-functional requirements explicitly, even if the initial numbers are estimates. They can be refined during discovery. Leaving them unstated means the supplier makes assumptions that may not match your operational reality.

Web application costs

How much does a web application cost?

There is no meaningful single answer to this question because a web application might be a modest internal tool replacing a spreadsheet or a complex multi-role platform with integrations, compliance requirements and high-availability infrastructure. The cost is driven by the number and complexity of the processes to be supported, the number of distinct user roles and permission sets, the volume and structure of the data, the number and nature of integrations with other systems, the non-functional requirements around performance, security and availability, and the quality of the specification and preparation work done before development starts.

A more useful framing is to understand what drives costs up and what keeps them contained. Clear requirements reduce rework. A well-defined scope reduces scope creep. Choosing the right level of technical complexity for the actual problem avoids over-engineering. And a realistic timeline — as opposed to an artificially compressed one — reduces the coordination overhead that inflates time-and-materials bills.

Hidden costs of web application development

The headline development price is rarely the full cost. Several categories of expenditure are routinely underestimated or omitted from initial budgets.

Discovery and specification work is sometimes assumed to be free or minimal, but thorough preparation is a paid activity — and the alternative, skipping it, is far more expensive in rework. Data migration — moving existing records from spreadsheets, legacy systems or paper into the new application — is frequently treated as an afterthought, yet it often requires cleaning, transforming and validating data, which is labour-intensive. Third-party service costs — API access fees, SaaS subscriptions for integrated tools, SSL certificates, domain registrations — accumulate over the life of the application. Training and change management — getting staff to actually use the new system — is a cost in time if not in money, and it is often the difference between a successful deployment and an expensive shelf-ware.

The way to handle hidden costs is not to guess at a percentage add-on but to identify each potential cost category during planning and either budget for it or make a deliberate decision to defer it.

How to compare quotes from different web development suppliers

Comparing quotes is difficult when suppliers have structured their proposals differently, used different levels of detail or made different assumptions about what is included. The first step is to ensure each quote is responding to the same specification. If one supplier has been given a detailed brief and another a one-paragraph summary, the quotes are not comparable.

Look beyond the total figure. Check what is explicitly included and what is excluded: design, discovery, testing, deployment, data migration, documentation, training, post-launch support. Check whether the quote assumes a specific technology or hosting arrangement that will create ongoing costs. Check whether the quote is fixed-price or an estimate based on time and materials, because the risk profile is fundamentally different. Check what happens if the scope changes — is there a defined change-control process, or will variations be billed at an open-ended rate?

The cheapest quote is often the most expensive in practice if it has omitted necessary work, made optimistic assumptions or been priced to win the work with the intention of recovering margin through change requests.

Contingency budgeting for software projects

Software projects involve uncertainty. Requirements evolve, technical unknowns surface during development, and external dependencies — third-party APIs, data quality, regulatory clarifications — do not always cooperate. A contingency budget is not an admission of poor planning; it is a recognition that uncertainty exists and will cost money if it materialises.

The question is how much to set aside. That depends on how well-defined the requirements are, how novel the technical challenges are, how much is being integrated with external systems and how much discovery work has been done before the build starts. A project entering development with a thorough specification, proven integrations and a clear architecture needs less contingency than one being built on a rough brief with untested assumptions.

Contingency should be a defined, ring-fenced amount, not a vague percentage. It should have an owner — someone with the authority to release it — and a trigger: what specific circumstances would justify using it. Without those disciplines, contingency either gets spent gradually without clear justification or becomes a political bargaining chip.

Choosing a web development supplier

How to choose a web-development company

Choosing a supplier is a procurement decision, not a creative judgement. The criteria should be grounded in what the project actually requires: can this team deliver a system of this complexity, with these integrations, to this standard, within this timeframe, with this level of ongoing support?

Evidence matters more than presentation. A polished pitch deck does not confirm technical competence. What does confirm it is the ability to talk through how they would handle specific aspects of your project — the data model, the permission structure, the integration approach, the testing strategy — in concrete terms rather than generalities. A supplier who cannot explain their approach to your specific requirements in plain language during a first meeting is unlikely to communicate clearly during a complex build.

Consider the team structure as well as the company. Who will be the day-to-day contact? Who will do the technical architecture? Who will write the code? Who will test it? A company that sells a senior team but staffs the project with juniors is a common source of disappointment.

Fixed-price vs time-and-materials contracts for web apps

Fixed-price contracts appear to transfer risk to the supplier, which is why they are popular with buyers. But the risk transfer is illusory unless the specification is complete and unambiguous. If the requirements are vague or likely to change, a fixed-price contract incentivises the supplier to interpret the brief narrowly, dispute change requests and deliver the minimum that technically satisfies the wording. The buyer pays for certainty but gets rigidity.

Time-and-materials contracts charge for actual hours worked. They provide flexibility to adapt as the project progresses, which is valuable when requirements are evolving or technical unknowns remain. The risk is that the final cost is not capped, which demands active scope management from the buyer's side. A well-run time-and-materials engagement with regular progress reviews, clear sprint boundaries and a shared understanding of priorities often produces a better outcome than a fixed-price contract fought over line by line.

A third option — fixed-price for well-defined phases combined with time-and-materials for discovery or uncertain elements — can capture the benefits of both approaches. The key is that the contract structure matches the nature of the work, not the buyer's preference for one model over the other.

Red flags when choosing a web development supplier

Certain behaviours during the selection process reliably predict problems during delivery. A supplier that promises an exact price and timeline before understanding the requirements in any detail is either not being honest or not being thorough. A supplier that dismisses your existing systems or data as "easy to integrate" without asking questions has not assessed the real work involved. A supplier that cannot name specific people who will work on your project, or who will not allow you to speak with the developers, is hiding something about capacity or capability.

Be wary of suppliers who resist a discovery phase. Discovery is not a sales upsell; it is the process of reducing the risk that both parties are about to commit to the wrong build. A supplier who wants to move straight from a brief conversation to a contract is prioritising their pipeline over your outcome.

Also be cautious of portfolios that show only visual designs with no explanation of what the systems actually do, what problems they solved or what happened after launch. A screenshot proves design ability; it does not prove delivery capability.

How to run a supplier discovery meeting

A discovery meeting with a potential supplier is not a pitch — it is a working session. The purpose is to test whether the supplier can engage with your requirements at a practical level, ask intelligent questions and identify risks and ambiguities that you may have missed.

Come prepared with a clear summary of the business problem, the users, the core processes and the known constraints. Present it concisely and then observe how the supplier responds. Do they ask about edge cases and exceptions, or do they accept the happy path at face value? Do they probe the integration requirements, or do they assume everything will connect smoothly? Do they raise questions about data quality, user adoption or operational readiness, or do they focus solely on building features?

The quality of a supplier's questions is a better indicator of their suitability than the quality of their answers. A supplier who asks "What happens when a user abandons the process halfway through?" is thinking about the real system. A supplier who only asks "What colour scheme do you prefer?" is not.

Web application ownership and rights

Who should own the source code?

Source-code rights determine who may use, modify and distribute the application. A business can preserve operational continuity through ownership or through a sufficiently broad licence combined with practical access to the repository, documentation and infrastructure. Without those protections, it may remain dependent on the original supplier for future changes and fixes.

Copyright ownership depends on how and by whom the work was created. In the UK, an employer will usually own qualifying work created by an employee in the course of employment, while commissioned work produced by an independent supplier does not automatically transfer to the customer. The contract should state clearly what is assigned, what is licensed and which pre-existing or third-party components remain under separate terms.

For a custom-built application, the business should negotiate rights that preserve operational continuity and future choice. Depending on the commercial model, that may mean an assignment of project-specific code or a sufficiently broad, perpetual and transferable licence. In either case, the agreement should distinguish bespoke work from reusable supplier components and third-party or open-source dependencies, and it should allow another competent supplier to maintain the system.

Intellectual property clauses in web development contracts

The intellectual property clause in a web-development contract should address several distinct elements. Ownership of custom code, as discussed above. Ownership of designs, wireframes and other creative assets produced during the project. The right to use any pre-existing components, frameworks or libraries that the supplier incorporates — and an obligation to disclose what those are. A warranty that the delivered code does not infringe third-party intellectual property rights. And a clear statement of what happens to IP if the project is terminated before completion.

A clause that simply says "all IP transfers to the client" may be incomplete if the supplier's standard terms, pre-existing components or third-party dependencies are not addressed. The agreement needs to be specific enough that both parties understand what is assigned, what is licensed and which restrictions continue to apply.

This is an area where current legal advice is essential. The guidance here explains what to look for and why it matters, not what your contract should say in precise legal terms.

How to ensure you control your web application's domain and hosting

Source-code ownership or licensing rights are not enough if the business cannot access or transfer the infrastructure the application runs on. A supplier that registers the domain in its own name, sets up hosting accounts under its own credentials and retains sole access to the server environment has effective control of the application regardless of who owns the code.

The business should register domains in its own name, with its own registrant details. Hosting accounts should be in the business's name, with the business holding the primary credentials. The supplier should have access granted to them — through role-based permissions, not shared logins — for the duration of the engagement. When the engagement ends, that access is revoked and the business retains full control.

This is not about distrust; it is about operational continuity. If the supplier becomes unavailable — through insolvency, dispute or simple unresponsiveness — the business must be able to keep its application running and engage a new supplier without the previous one's cooperation.

What happens to your code if a developer closes down

Supplier insolvency is a risk that most businesses do not plan for until it happens. When a development company closes, its assets — including source code repositories, hosting credentials and documentation — may be tied up in administration, sold to a third party or simply lost if proper backups were not maintained.

Effective protection combines contractual rights with practical, regularly tested access arrangements. The business should ensure that the source-code repository is either hosted under the business's own account — with the supplier having access as a collaborator — or that regular, verified copies of the code are in the business's possession. All credentials, keys, certificates and access details should be documented and stored independently of the supplier. Infrastructure should be under the business's control, as described above.

Source-code escrow — where a third party holds a copy of the code and releases it under defined conditions, such as supplier insolvency — is sometimes recommended but is of limited practical value if the code is not accompanied by documentation, build instructions and access to the hosting environment. A codebase without the knowledge to deploy and maintain it is only marginally better than no codebase at all.

Web application support and maintenance

What does web application support include?

Support and maintenance are not a single activity. They encompass several distinct functions, and a support arrangement that does not distinguish between them will produce confusion about what is covered and what is not.

Bug fixing addresses defects in the existing system — behaviour that does not match the agreed specification. This is the core of what most businesses mean by support. Updates and patches cover the application's dependencies — operating-system updates, framework security patches, library version upgrades — that must be applied to keep the system secure and compatible with its environment. Infrastructure management covers server health, backups, monitoring and capacity. Feature development is the addition of new functionality beyond the original scope, which is a separate commercial arrangement, not support.

A clear support agreement defines which of these are included, what the response times are for different severity levels, how requests are logged and tracked, and what the monthly or annual cost covers. Without that clarity, both parties develop different expectations, and the relationship deteriorates.

How to plan for web application updates and patches

Every web application sits on top of a stack of dependencies: the operating system, the web server, the application framework, the database engine, the front-end libraries and any third-party packages. All of these receive updates over time, and some of those updates address security vulnerabilities.

Skipping updates is a false economy. Each deferred update increases the technical debt and the size of the eventual catch-up, which raises the risk of breaking changes and extends the testing window. But applying updates blindly is also risky — a framework upgrade can introduce incompatibilities with custom code.

The practical approach is a scheduled update cycle: a regular cadence — monthly or quarterly, depending on the criticality of the system — during which available updates are reviewed, risk-assessed, applied to a staging environment, tested and then deployed to production. This is not a task that can be left to ad-hoc attention; it needs to be planned, resourced and tracked like any other operational process.

Transitioning between web development suppliers

At some point, most businesses need to change their development supplier — whether because of cost, capability, capacity or relationship breakdown. The ease of that transition is determined largely by decisions made before the transition becomes necessary.

A smooth handover requires: the business to control the code repository, hosting environment and domain, as discussed earlier; up-to-date technical documentation covering the architecture, data model, deployment process and known issues; a defined handover process in the support contract, specifying what the outgoing supplier must provide and within what timeframe; and a sensible overlap period where the incoming supplier can shadow the outgoing one, ask questions and verify their understanding before taking full responsibility.

The worst time to discover that documentation does not exist, credentials are missing or the code is incomprehensible is during a forced transition. If the current supplier cannot or will not provide adequate documentation, that is a signal to address the gap before it becomes an emergency.

Planned vs emergency maintenance for business systems

Planned maintenance is scheduled, predictable and can be performed during low-usage windows with appropriate notice to users. It includes update cycles, performance tuning, capacity adjustments and minor improvements identified through monitoring. Emergency maintenance is unplanned, driven by a failure or security incident, and happens on the system's timetable, not the business's.

The goal of good operational practice is to maximise planned maintenance and minimise emergency maintenance. That does not mean emergencies will never happen — hardware fails, zero-day vulnerabilities are discovered, unexpected load patterns emerge — but a system that is regularly updated, monitored and tested will experience fewer emergencies and recover from them faster.

The support agreement should define both. Planned maintenance should have a schedule and a communication protocol. Emergency maintenance should have defined severity levels, response-time targets and escalation paths. A system that treats all maintenance as emergency maintenance is a system that has not been properly operated.