When to build a QGIS plugin instead of a web app

There’s a decision that comes up on nearly every project: someone has a repetitive GIS task, and the instinct is to “put it online.” Build a web app, a dashboard, a portal. Sometimes that’s right. Often it isn’t, and the team ends up rebuilding a worse version of the tool their analysts already have open all day.

Here’s the distinction we keep coming back to.

The work is analyst-driven and the data is heavy

If the person doing the work is a GIS analyst, and the data is large, local, and changes hourly, a web app is usually the wrong shape. You’d be uploading gigabytes to a server, waiting on round trips, and forcing someone to leave the environment where they already have their layers styled, their CRS sorted, and their muscle memory built.

A QGIS plugin, a Processing script, or a custom model lives inside that environment. It reads the layers already loaded. It writes outputs straight into the project. The analyst never context-switches. When the goal is to remove repetitive manual steps, this is almost always the cheaper, faster path.

Concretely, that looks like:

• A Processing script or model that chains the six steps someone runs by hand every Monday into one button.
• A custom toolbar that standardizes an office’s clip-buffer-export routine so every analyst does it the same way.
• A batch tool that runs the same operation across 300 files without anyone babysitting a dialog box.

None of these needs a server, a login, or a deployment pipeline. That’s the point.

Be honest: sometimes you don’t need software at all

Before you commission anything, check whether the automation already exists. QGIS ships with a large Processing toolbox, and a graphical model or a 20-line PyQGIS script often does the whole job. If a Processing model does it, use the Processing model. We’d rather tell you that than sell you a plugin you didn’t need.

The test is simple: can an off-the-shelf tool, configured, do this — or am I fighting the tool? If you’re not fighting it, don’t build software. If you are — the operation doesn’t exist, or it exists but you run it fifty times a day by hand — that’s when a workflow or processing plugin earns its keep.

When a web app actually is the answer

The web app wins when the audience stops being GIS people.

If the goal is to share results with a board, a regulator, a landowner, or the public, nobody’s installing QGIS to look at them. If you need a single source of truth that ten people read and two people edit, a plugin on one analyst’s laptop won’t hold it. If the deliverable is a public-facing or investor-facing map, that’s a product, not a geoprocessing step.

So the split is roughly: plugins and geoprocessing automation for the doing; web apps and platforms for the sharing and the source of truth. Repetitive analyst work that stays local pulls toward a plugin. Communication, access control, and durable shared state pull toward a web app. Most teams need a bit of both, and the mistake is using one to do the other’s job.

Where we sit

We build both, and part of the job is telling you which one you actually need — sometimes that’s a small Processing script we’d hand you and walk away from, sometimes it’s a platform. If you’re not sure which side of the line your problem falls on, that’s exactly the kind of thing a short audit sorts out. You can also see the range of what we take on in capabilities and work, or just get in touch.