Web Application Development
Somewhere between a website and a piece of installed software sits the thing most businesses actually need: an application that runs in a browser, that people log into, and that does work rather than describing it. Customer portals. Internal dashboards. Booking systems. Approval workflows. The tools that replace a shared spreadsheet and an email chain.
Discovery on site where possible, watching the process the application will replace · A written scope, a fixed price for phase one, a timeline and explicit exclusions · A clickable prototype of the main screens before development starts · Two-week build sprints, each ending in a version you can log into
On this page
- What is a web application, and how is it different from a website?
- What kinds of web application do we build?
- Can you build the API behind the application?
- Do you need a web app, a mobile app, or a progressive web app?
- What is our honest position on this?
- How do you keep a web application secure?
- Where does the application run, and who keeps it running?
- What happens if you want to move to another developer?
- What should you ask before someone builds you a web application?
- What drives the cost of a web application?
- What moves the cost, and what should you budget separately?
What is a web application, and how is it different from a website?
A web application is software that runs in a browser and lets people do things — log in, enter data, complete transactions, get results back. A website presents information; a web application processes it. That single distinction is what separates a brochure-site quote from a software quote, and the gap between the two is not a small one.
The practical difference is what happens when you visit. A website shows you the same content it shows everyone. A web application shows you your content — your orders, your bookings, your dashboard, your documents — because it knows who you are and has a database behind it.
Everything else follows from that. A web application needs user accounts, permissions, a database, security appropriate to the data it holds, and a plan for what happens when two people change the same thing at once. A website needs none of those. Familiar examples: online banking, a project management tool, a supplier portal where you check order status, a booking system, an internal reporting dashboard.
Why it matters commercially: the two are priced completely differently, and a lot of businesses go to a web design agency asking for a “website” and describe an application. The quote comes back low, the project runs into trouble, and everyone is unhappy. If what you need really is a brochure site with a contact form, a content-managed website build is the cheaper and better answer, and we will say so.
What kinds of web application do we build?
Seven kinds: customer portals, internal dashboards, booking and scheduling systems, workflow and approval tools, data and reporting platforms, progressive web apps, and applications with a checkout attached. The portal is the most common first project, because every self-served customer query is one your team does not answer by email.
- Customer and client portals. Somewhere your customers can log in and self-serve: order status, documents, invoices, quotes to approve, requests to submit, history to look back at. Usually the fastest-paying build on this list.
- Internal dashboards and admin tools. Live figures from the systems that hold them, presented as the questions your managers actually ask. Replaces the monthly export-and-assemble ritual.
- Booking and scheduling systems. Availability, resources, staff, rooms, equipment, confirmations, reminders, rescheduling, cancellation rules, calendar sync. Deceptively hard to get right, which is why so many businesses run them on a spreadsheet and a phone.
- Workflow and approval systems. Multi-step processes with roles, rules, sign-offs, escalations and an audit trail. Anything currently held together by an email chain and a shared folder.
- Data and reporting platforms. Pulling data from several systems into one place people can query, with proper access control over who sees what. Where the data in question is sales data, this often overlaps with a CRM built around your pipeline.
- Progressive web applications. Applications that behave like an installed app on a phone — home screen icon, offline capability, push notifications — without an app store. Often the sensible middle ground when someone thinks they need a mobile app.
- Applications that sell as well as serve. Where the portal has a checkout attached, the same team handles the store and its payment flow rather than handing it to a second supplier.
Can you build the API behind the application?
Yes, and it is frequently the larger half of the work. An application is a window onto a server: user accounts, data storage, business logic, integrations, and the endpoints everything else talks to. Clients rarely budget for that part and always need it.
We build APIs so your systems, your partners or your customers can connect to your data securely — REST or GraphQL, with webhooks where an event needs to push rather than be polled, and authentication and rate limiting appropriate to who is calling it. We also consume other people's APIs, including the ones where the documentation is poor or absent, which is more common than vendors admit.
Where a system offers no API at all, there is often still a route: direct database integration, or a scheduled file exchange. We check what your systems can genuinely do during discovery rather than assuming, because integration is where optimistic estimates go wrong. If the integration turns out to be the whole project, it is usually better scoped as a bespoke software build in its own right.
The point
Where a system offers no API at all, there is often still a route: direct database integration, or a scheduled file exchange.
Do you need a web app, a mobile app, or a progressive web app?
A web application if people will use it at a desk or on a tablet and you want one build covering every device. A mobile app if it needs deep device features or store presence. A progressive web app sits between them. Genuinely worth thinking about before spending, because the costs are very different.
| Option | When it is usually right |
|---|---|
| Web application | People will use it primarily at a desk or on a tablet. It needs to work across Windows, Mac, iOS and Android without three builds. You will update it frequently — no app store review, everyone on the current version instantly. Users are staff, customers or partners you can send a link to. And the budget matters, because one build covers every device. |
| Mobile app | It needs deep device features — the camera in a specific way, GPS in the background, Bluetooth hardware, offline for long periods. Push notifications are central rather than useful. It must appear in the App Store or Play Store for discovery or credibility. Or performance demands are high: heavy graphics, real-time processing. That is a native or cross-platform app build. |
| Progressive web app | Home screen presence, offline capability and push notifications on most platforms, from one codebase, with no store submission. Not right for everything, and often right for the thing someone assumed needed a native app. |
What is our honest position on this?
We build both, and we sell more web applications than mobile apps because that is what more businesses actually need. If you come to us asking for a mobile app and the requirement is really a responsive web application, we will tell you — it is usually a smaller invoice and a better outcome.
How do you keep a web application secure?
Applications hold data that matters, which changes the standard. Authentication, permissions, encryption, audit logging, GDPR handling and performance under load are designed at the start rather than bolted on afterwards, because every one of them is disproportionately expensive to add once the application is live and holding real records.
- Authentication and access control. Proper session handling, password policy, two-factor authentication where the data justifies it, single sign-on where you use Microsoft 365 or Google Workspace, and role-based permissions designed at the start.
- Data protection. Encrypted in transit and at rest. UK or EU hosting as standard. Backups tested by actually restoring them.
- Audit trails. Who did what, when. Essential for anything with approvals, money or compliance, and very hard to add retrospectively.
- GDPR by design. Lawful basis recorded, retention rules configurable, subject access and erasure handled through the interface rather than by a developer running database queries.
- Performance under real load. Applications behave differently with 500 concurrent users than with five. Where volume justifies it we load-test before launch rather than discovering the ceiling in production.
- Monitoring. Uptime, errors and performance watched continuously, with alerting. We would rather know before you do.
Where does the application run, and who keeps it running?
On UK or EU cloud infrastructure, in an account registered to you, with deployment automated rather than done by hand. That last point matters more than it sounds: a deployment somebody performs manually at nine in the evening is the one that goes wrong, and it is the reason a small change starts to feel risky.
We use containerised deployment so the application behaves the same in staging as it does in production, automated backups that are tested by restoring them rather than assumed to work, and uptime, error and performance monitoring with alerting. Where volume justifies it we load-test before launch instead of discovering the ceiling in production.
Hosting can sit with us as part of a support arrangement, or in your own cloud account if you prefer. Either way the account is in your name, so you are never locked out of your own application — the same principle we apply to code ownership and to the accounts behind a website we build.
The point
Hosting can sit with us as part of a support arrangement, or in your own cloud account if you prefer.
What happens if you want to move to another developer?
You leave with everything needed to run the application without us. The handover is a defined package rather than a gesture of goodwill: the repository, the data, the credentials, the documentation and the accounts. A competent developer should be able to deploy it from that package alone, on infrastructure you already hold.
- The repository with its full commit history, not a zip of the current files, so whoever picks it up — a freelancer, an agency or an in-house hire — can see why the code is the way it is.
- The database schema and a full data export in a standard format, so the application can be stood up elsewhere with real records in it rather than as an empty shell.
- Environment variables and third-party credentials — payment keys, mail and SMS providers, storage buckets, mapping and analytics services — listed with what each one is for and which account it belongs to.
- The API documentation: endpoints, authentication, rate limits and webhook payloads, covering everything described in the API layer that sits behind the application.
- Deployment and build instructions — how to run it locally, how a release reaches production, and what the automated pipeline does at each step.
- The role and permission model written down, with the audit logging it depends on, because a permissions grid nobody documented is the thing a new team gets wrong first.
- The domain, DNS, hosting and monitoring accounts, already registered in your name — the same principle that applies to the accounts behind a business system we build.
What should you ask before someone builds you a web application?
Eight questions, and the answers tell you more than the quote does. Ask about browsers, offline behaviour, data custody, permissions, concurrency, staging, support and exclusions. A developer who has built applications before answers each one specifically; one who has only built websites answers in generalities, and that is the signal you are listening for.
- “Which browsers and versions will you test this against?” A good answer names them, and names what the application does on the ones outside that list. Browser tolerance is wider for a brochure site with a contact form than for software a finance team uses all day.
- “What does it do when the connection drops?” A good answer is a specific behaviour — a warning, a queued save, a read-only mode — rather than the word “offline”. Genuine offline capability is designed in at the start, and it is often the question that decides between a browser build and a native one.
- “Who holds the data, and how do I get a copy of it?” A good answer names the host, names the account holder, and describes an export you can request without a developer writing a query — which is most of a clean handover to another team.
- “How are permissions handled when someone changes role or leaves?” A good answer describes roles defined at the start and an audit trail that records the change. A vague one usually means permissions are about to be written as conditionals scattered through the code.
- “How many people can use it at once, and what happens when two of them edit the same record?” A good answer names a strategy — locking, last write wins with a warning, a merge — and says how concurrency was tested rather than assumed.
- “Is there a staging environment I can see it on before it goes live?” A good answer is yes, with your own data in it, and a deployment that is automated rather than performed by hand at nine in the evening.
- “What exactly does the support arrangement cover?” A good answer separates a bug from a change, says who handles security patches and dependency updates, and puts both in writing — the same distinction that governs looking after a site after launch.
- “What is not in the price?” A good answer is a written exclusions list covering hosting, third-party services and the work deliberately left to a second phase. Its absence is why bespoke software quotes are so hard to compare.
What drives the cost of a web application?
The cost of a web application is driven by how much it has to know about who is using it. Role count and permission complexity move the figure most, then how many systems it integrates with and whether those have usable APIs, whether it needs offline capability, and the state of any data being migrated.
| Scope | Typically |
|---|---|
| Focused application | One clear purpose. A customer portal, a booking system, a reporting dashboard. One or two user types, a handful of screens, one or two integrations. Eight to twelve weeks. |
| Business platform | Multiple user roles, complex permissions, several integrations, data migration, substantial workflow. Four to six months. |
| Large platform | Multi-organisation, high volume, complex integration with production or finance systems. Scoped individually, because no two are alike. |
What moves the cost, and what should you budget separately?
Five things move the build price, and three running costs sit outside it. Hosting for a business application scales with load and concurrency rather than sitting at a flat fee, and we set every running cost out in the proposal rather than leaving you to discover them after launch.
- The number of distinct user roles and how complex the permission rules are
- How many systems it integrates with, and whether they have usable APIs
- Whether it needs offline or mobile capability
- The state of any data being migrated
- How settled the requirements are before we start
- Running costs: hosting, which scales with load and concurrency; third-party services such as email delivery, SMS or payment processing, most of which meter by volume; and ongoing support or development
How We Work
Discovery
On site where possible, watching the process the application will replace. The documented process and the real one are rarely the same, and the gap is where projects fail.
Scoping and prototyping
A written scope, and a clickable prototype of the main screens. Changing a prototype takes hours; changing built software takes weeks.
Fixed-price phase one
Written scope, fixed price, timeline, explicit exclusions. Where requirements are genuinely unclear we propose a short paid discovery rather than pricing a guess.
Build in two-week sprints
A working version you can log into at the end of each one, deployed to a staging environment throughout.
Explore Related Services
Frequently Asked Questions
What is the difference between a web application and a website?
A website presents information to everyone equally. A web application lets people log in and do things — enter data, complete transactions, see their own records — with a database behind it. Applications need user accounts, permissions and security that websites do not, which is why they cost considerably more to build than a content-managed website.
How much does a web application cost to build in the UK?
Scope drives it. The biggest variables are how many distinct user roles there are and how complex the permission rules get, how many systems it must integrate with and whether those have usable APIs, whether it needs genuine offline capability, and the state of any data being migrated.
Do I need a web app or a mobile app?
A web application if people will use it at a desk or on a tablet, if it must work across all platforms, or if you will update it often. A mobile app if it needs deep device features, background GPS, hardware connections, or app store presence. A progressive web app covers much of the middle ground.
What is a progressive web app?
A web application that behaves like an installed app — home screen icon, works offline, push notifications on most platforms — without going through an app store. One codebase covering every device, instant updates, no submission process. It is not right for everything, and it is right more often than people assume.
Can you build an API for our existing systems?
Yes. We build APIs so your systems, your partners or your customers can connect to your data securely — REST or GraphQL, with webhooks where events need to push rather than be polled. We also consume other people's APIs, including the poorly documented ones. Where a system offers no API, direct database integration or a scheduled file exchange is usually workable.
How do you keep a web application secure?
Proper authentication with two-factor where the data justifies it, role-based access control designed at the start, encryption in transit and at rest, audit logging, dependency monitoring and regular patching, UK or EU hosting, and tested backups. Security is an architecture decision, not something added after a penetration test.
Can it work offline or on mobile?
Every application we build is responsive and works on a phone. Genuine offline capability — continuing to function without a connection and syncing later — is a design decision made at the start, because retrofitting it is expensive. If your users are in vans, on sites or in buildings with poor signal, say so at scoping.
Who hosts the application once it is live?
Usually us, on UK or EU infrastructure, included in a support arrangement — with automated deployment, monitoring and backups. Or your own infrastructure if you prefer, or your existing cloud account. The hosting account is registered to you either way, so you are never locked out of your own application.
What happens if we need changes after launch?
Expected. The first three months always surface things nobody anticipated. We work on a support retainer or a day rate, whichever suits. You own the code, so you can also take it elsewhere or bring it in-house — we will help with the handover if you do.
Let's Build Something That Matters.
Tell us what you're trying to achieve and we'll help you find the right solution.