QGIS plugin development

SPEC

Technical spec

Map: QGIS
Scripting: Python
PyQGIS
Qt

FIT

A good fit when

The work is already scripted, but the people who need it cannot run scripts
Several people have to use the same tool in the same way
A tool has to be distributed and updated across an in-house QGIS environment

PREBUILT

Example components

These components illustrate the proposed structure. Template features and scope will be confirmed after implementation and verification.

Plugin skeleton: metadata.txt, menu and toolbar registration, icon, and entry point: the minimum structure QGIS recognises on install.
Qt dialog template: A dialog shell with input validation, a progress indicator, and cancel handling, used as is.
Custom repository distribution: XML repository configuration and version rules, so the plugin installs and updates from an in-house address.
Install and usage guide: A document template that walks from repository registration to the first run, screen by screen.

The layout and design are adapted to each project.

SCREENS

Example screens

Example screens to explore layouts and flows. The final template design and style have not been decided yet.

A QGIS plugin manager settings dialog with fields for a custom repository name and URL. — Custom repository registration · The distribution repository name and URL are added in the plugin manager settings.

A QGIS plugin manager screen showing a plugin search result and the install button. — Search and install · Once the repository is connected, the plugin is found and installed from the plugin manager.

SCOPE

In scope

Deliverables

An installable QGIS plugin package
Source code with build and install instructions
Usage documentation

In scope

Feature definition and screen layout based on the workflow
Plugin implementation and error handling
Install and behaviour verification on the agreed QGIS version
One revision round after acceptance

Out of scope

Submitting to the official QGIS plugin repository on your behalf
Building server systems and managing accounts
Fees for third-party commercial APIs
Adding further language translations

Scope and exclusions are defined before the work starts. The schedule and detailed terms are fixed in the SOW after we talk.

The problem this solves

Scripts often end up being run only by the person who wrote them. As a plugin, the same tool stays usable in the same way even when the person responsible changes.

How it runs

Review the workflow and the required inputs and outputs.
Fix the screen layout and feature list in the SOW.
Implement the plugin and verify error handling.
Deliver the install package and accept it in the real environment.

Scope versus additional development

A feature listed in the SOW that does not work is a defect. A new screen or feature not in the SOW is additional development and goes through the change-request process.

FAQ

Frequently asked questions

Can an existing script become a plugin?: Yes. When a working script already exists, the feature-definition stage is shorter and the overall schedule shrinks.
Can it connect to an internal server?: If the target API already exists and access is confirmed, it can be included in the scope. Building the server itself is a separate service.

Need a particular setup?

Tell me which screens and integrations you need, and I will come back with what is feasible.

Ask about this setup