Web app or desktop app? Choosing the right shape for an internal business tool

When a business decides to replace the spreadsheet or the ageing database that runs a part of its operation, one of the first questions asked is whether the replacement should be a web application or something installed on the PCs.

It is usually framed as a technical question. It is not. It is a question about where your people are, what they need to do when they get there, and who will look after the thing in five years' time.

Here is how we work through it, including the cases where the answer is not the one you would expect.

What the two things are

A web application runs on a server and is used through a browser. Nothing is installed on anyone's machine. It may sit on the public internet behind a login, or on your own network only, which is a configuration choice rather than a different kind of software.

A desktop application is installed on a Windows PC or a Mac and runs there. It may still talk to a central database over your network, and often does. What makes it desktop is that a copy of the program lives on each machine.

Almost everything else people argue about, whether it looks modern, whether it is fast, whether it handles lots of records, is a consequence of how it was built rather than which of these two it is. Both can be good. Both can be dreadful.

Start with where the work happens

This single question settles most projects.

If the people using the system are ever away from a company desk, on a customer site, in a van, in a warehouse, at home on a Friday, working from a phone or a tablet, you want a web application. There is no version of a desktop program that makes that easy. The workarounds, remote desktop sessions and VPN clients and a laptop that has to be carried, are exactly the friction that makes people stop using the system and go back to paper and WhatsApp.

If every user sits at the same fixed workstation, on your network, every day, that constraint disappears and the field is genuinely open.

Worth being honest with yourself here. "Everyone is always in the office" is true of fewer businesses than it was, and the answer you want is not "where do people work now", but "where will they need to work over the life of this system", which is likely to be seven to ten years.

The case for a web app

For most internal business tools, a web application is now the default, and for practical reasons rather than fashionable ones.

Nothing to install, nothing to update. You deploy a change once and everyone has it. No rollout, no machine that got missed, no two versions in use at the same time. For a small business with no IT department, this is the biggest single saving and it never stops paying.

It works on whatever people have. A new starter is productive on any device with a browser. A director can look at last month's figures on a phone.

It integrates outwards more naturally. Your accounts package, your payment provider and your customers' systems all speak over the web already, so a web application is sitting in the right place to talk to them. That is the work we describe on our system integration page, and it is a good deal simpler when the system is already server-side.

Backups and security live in one place. One server to patch and back up, rather than data scattered across whichever PCs happen to hold a copy. If you are being asked about Cyber Essentials or filling in a customer's security questionnaire, that is a much easier story to tell.

Supplier risk is lower. Web technologies are the mainstream, so the pool of developers who can pick your system up later is larger. Our guide on what happens if your developer disappears covers why that matters more than most people assume at the start.

The case for a desktop app

There is a real one, and it applies to a minority of projects.

Heavy work on the local machine. CAD, CNC output, large image or video processing, engineering calculations over very large files, anything where the data sits on the machine and moving it to a server is the slow part.

Deep hardware access. Some older or specialist equipment, certain label printers, measurement instruments, machine controllers, only exposes a driver that a desktop program can reach. Browsers deliberately sit behind a wall here. If your process depends on one of these, check what it actually supports before deciding anything else.

Genuinely offline, all day. Not "the wifi is patchy", which good web applications handle, but sites with no connectivity at all for long stretches.

Tight integration with locally installed software. Driving Excel, Outlook or a desktop accounts package directly, in a way that would be awkward to replicate server-side.

Notice that none of these are about preference or familiarity. If the reason for wanting a desktop application is that the current one is a desktop application, that is worth examining rather than assuming, and it is the same trap we describe in our guide to Microsoft Access end of life: replacing like with like preserves the limitation along with the familiarity.

The middle options people forget

The choice is not always binary.

A web app installed to look like an app is a real and useful halfway house. Modern browsers let a web application be pinned to a taskbar or a home screen and opened in its own window with no browser furniture, and it can cache enough to keep working through a patchy connection. Microsoft, Google and Apple all support this; Mozilla's developer documentation sets out what is and is not possible. For most staff, the difference from an installed program is invisible.

A small desktop companion alongside a web system is the other. The main application is on the web, and one narrow piece, the bit that talks to the label printer or watches a folder for files, is a small installed utility on the one or two machines that need it. You get the benefits of the web system and solve the hardware problem without building everything twice.

Four questions that decide it

1. Will anyone need this away from a company desk, ever? If yes, web.
2. Does it have to talk to specific local hardware, or move very large files around? If yes, desktop, or a web system with a desktop companion.
3. Who will install updates? If the honest answer is nobody, web.
4. How long do you expect to run it? The longer the horizon, the more the maintenance and hiring argument favours the web.

Only the second question genuinely points away from the web, which is why the default has moved. But when it applies, it applies absolutely, and building a web system that cannot reach the machine it needs to reach is an expensive way to find out.

What it does not change

Whichever shape you choose, the things that determine whether the project succeeds are the same: understanding the process properly, validating data at the point of entry, permissions that match how people actually work, and a supplier who can change it when the business changes. The shape is a delivery decision, not a quality one, and it has less effect on timescales than most people expect, which our guide to how long bespoke software takes goes into.

If you are weighing this up for a specific system, it is usually a twenty minute conversation rather than a research project. Tell us what the tool has to do and where people need to do it, and we will tell you which way it points, including when the answer is that your current system is fine. The contact page is the quickest way to start.