To sell a QGIS project template, deliver the editable project together with the data and assets needed for the outcome you advertise. A QGZ project file should not be treated as a complete data package. Verify a separate release copy, describe external dependencies, and distribute the approved bundle as a ZIP with clear opening instructions.
This guide is for GIS consultants selling their own reusable mapping workflows. Its original manifest and six acceptance checks connect project preparation to paid file delivery. They are a protocol to run on your release, not a claim that PayRequest rendered or tested your map.
Define the Buyer's Actual Deliverable
Decide whether the buyer receives a finished map, an editable project using sample data, a self-contained offline bundle, or a project that requires external services. Those offers have different dependencies and support obligations. A preview image should not imply that every displayed layer is included.
The QGIS project documentation distinguishes saved project settings and QGZ packaging from referenced data sources. A project can fail to open layers when a file moves or a service is unavailable. Do not infer completeness from the QGZ extension.
Write one specific promise, such as “an editable site-survey layout with fictional sample layers and an opening guide.” State the QGIS version you actually checked and what the buyer must supply. Do not label a project compatible with every version without evidence.
Use a Package Manifest
Here is an illustrative manifest for a site-survey template. The filenames are examples, not a downloadable GIS dataset or proof of redistribution rights.
| Package item | Example | Acceptance question |
|---|---|---|
| Editable project | survey-template.qgz | Does it reference the release files? |
| Vector data | data/sample-survey.gpkg | Are every required layer and field present? |
| Raster, if included | data/sample-elevation.tif | Is the advertised coverage included? |
| Layout assets | assets/ | Are required symbols and fonts available or disclosed? |
| Buyer guide | START-HERE.pdf | Does it identify the folder to open and requirements? |
| Usage terms | LICENSE.txt | What can the buyer use and redistribute? |
Keep the project and its packaged dependencies together. If you use relative file paths, verify them from the extracted release folder. A shortcut back to your working drive is not a delivered asset. Online layers should be listed as external dependencies rather than counted as included files.
Run Six Acceptance Checks on a Release Copy
Run these checks before publishing. Record the archive filename, release version, review date, operating system and QGIS version; mark each result only after observing it yourself.
- Extract the ZIP into a new location away from your working folder. Open the delivered project, not a recent-project shortcut.
- Check every required layer for missing sources. Inspect a known feature and its expected fields; a visible layer name alone is insufficient.
- Check the declared coordinate reference system and a known location. Record what should appear there so a buyer can compare.
- Open the advertised layout and export a preview. Review fonts, symbols, legend and required raster coverage against the offer.
- Test the promised dependency boundary. For an offline offer, verify it without network access; for an online offer, document the required service and buyer access.
- Open the guide from the delivered ZIP and follow its first steps. Confirm the release identifier matches the listing and preview.
If a check fails, revise the release copy and repeat the affected checks. Do not ask buyers to repair your private file paths as an undocumented installation step.
Separate Your Template Rights from Data Rights
Keep a source-and-rights register for the notes, vector data, rasters, symbols and fonts you include. Your authorship of the map layout does not establish permission to redistribute every underlying asset. Consult each source's current terms before bundling it; omit private survey information and credentials.
If a service requires the buyer's own account, state that before purchase. Avoid embedding authentication details to make a demonstration work. For sample data, disclose that it is illustrative and unsuitable for decisions requiring verified geographic accuracy.
A finished PDF can be a useful alternative when buyers only need the static output. An editable project fits buyers who need to change data or layout. Match the file to the intended task instead of automatically promising both.
Prepare Delivery in PayRequest
PayRequest's Digital Products documentation supports an Other digital download file route and ZIP delivery. Prepare your verified bundle, choose that product type, and write software requirements and opening instructions into the offer. Configure the supported download-access settings for your delivery promise.
PayRequest handles the supported file-delivery workflow; this is not a native QGIS renderer, GIS data auditor or source-license verifier. Review the file buyers receive before presenting the product as ready.
Start with Digital Products and the Digital Downloads overview. Publish the release only when the package manifest and buyer promise agree.
Prepared by the PayRequest Team with AI assistance. Documentation was reviewed on 9 October 2026. The manifest and acceptance protocol are original editorial examples, not a tested commercial dataset.
