Choosing between WPF and web for internal tools

A narrower question than it looks

Internal tools have properties that change the calculation. You control the machines. You know the users by name. Nobody is discovering the software through a search engine, and there is no marketing case for it working on a phone.

That removes most of the usual arguments for the browser and leaves a specific question: is this tool's job better served by a dense, fast, local client or by something reachable from anywhere with an update path that costs nothing?

Where WPF still wins clearly

Dense data work. A grid of several thousand rows with instant sort, filter and inline editing, driven entirely by keyboard, remains easier to build well in WPF than in the browser. Users who spend their whole day in one screen notice the difference within an hour.

Local hardware and file system access. Label printers, scanners, scales, serial devices, bulk file operations, and anything that needs to watch a folder. Achievable in a browser only with a local helper, which is another thing to deploy and support.

Extending other Windows software. If the requirement is a plugin inside an application your business already runs, the decision is made externally.

Genuine offline operation. A local database as the primary store, with sync as an enhancement, is the natural WPF architecture and an uphill one on the web.

Where the browser wins for internal tools

Anything that is used occasionally by many people: approvals, requests, lookups, dashboards, timesheets. Installing software on forty machines for a task someone performs twice a week is poor value.

Anything that needs to be reachable from home, from a client site or from a phone. That has stopped being an edge case and it is where we see most new internal work landing.

Anything that changes frequently. Web deployment means a fix is live in minutes for everyone, with no version skew and no support calls about old builds. On a tool under active weekly change, that advantage compounds.

Anything where your team's existing skills are web skills. Maintainability by the people who will actually maintain it beats a marginally better technical fit.

Build the core so the decision is reversible

Whichever you choose, keep the business rules out of the client. Put them behind an API, with the client responsible for presentation and interaction only. Then the choice is a front-end decision rather than an architectural one, and adding the other client later is additive work rather than a rewrite.

This is what we do by default on internal systems, because the second client almost always arrives: a desktop tool for the operations team, then a web view for managers, then a mobile screen for someone on site.

The pattern also protects you from your own preferences. Rules in one place, enforced on the server, means the two clients cannot drift apart.

A practical way to decide

Count the hours. Roughly how many hours a week will the heaviest user spend in this tool? Above about ten, weight density and keyboard speed heavily, which favours WPF. Below about two, weight convenience and reach, which favours the browser.

Then ask where they will be sitting, and what the tool has to touch. Between those three answers, the choice is usually settled in a single conversation.

If it is genuinely balanced, choose the browser and keep the API clean. It is the cheaper option to run and the easier one to change your mind about later.