Systems that stayed switched on.

Problem

Zimbabwe's cadastral record was paper-based and fragmented. A surveyor lodging a diagram, an examiner checking it and a citizen searching a title were all working from different copies of the truth, and none of them could query it spatially. Worse, the registers that had to agree with each other — deeds, mining, the investment one-stop shop — had no way to talk at all.

Approach

A national digital cadastre: PostGIS geodatabases designed end to end, the statutory lodgement-to-examination workflow modelled in GeoDjango, geodesy control layers, and authoritative parcel layers published as OGC services through GeoServer and consumed in OpenLayers. Bulk ingest of legacy records with geometric and topological validation, so examiners work from exceptions rather than reading every submission. I designed and built every API, and the integrations that put the eCadastre in conversation with the Deeds system, the One Stop Shop and the Mining Cadastre.

Outcome

Live in production and in daily use by surveyors, examiners and the public, serving property search, e-maps, cadastral and geodetic services. I owned the spatial architecture — schema, validation rules and service layer — and the integration layer across four national registers, as part of a team of five-plus developers.

Problem

Mortgage applications were paper-driven. A loan officer assessing a property had no way to see it spatially, and no path between a valuation and the bank's core systems that did not involve re-keying.

Approach

A GeoDjango and OpenLayers platform where a customer browses and evaluates properties on a map and applies against them directly, integrated with the bank's core banking, payment and SMS gateways over REST and SOAP.

Outcome

The first GIS-driven mortgage platform in Zimbabwean banking, live in production. End-to-end digital application, with spatial evaluation in the officer's workflow rather than beside it.

Artwork © CBZ Bank

Problem

Leads arrived from a website form and a shared inbox, and were worked by hand. Follow-up depended on who happened to read the message, nobody could say who had been contacted or what had been promised, and a lead that went cold left no trace of why.

Approach

An agent that watches the inbox and the website's lead forms, identifies and enriches the prospect, drafts outreach, and writes every contact back to a record. The draft is built from retrieval over the company's own past email threads, so the tone is learned from what they actually send rather than described in a prompt — and it keeps improving as more correspondence lands. A separate prospecting pass goes looking for candidate clients the inbox never produced.

Outcome

Nothing leaves the building without a human approving it. The approval gate is the architecture, not a setting: the agent researches, drafts and queues, and a person decides. That is what makes it safe to point at real customers.

Problem

An investor looking at African opportunities had nowhere to compare them. Prospects sat in brochures and inboxes, with no way to filter by industry, sector, commodity or country, and no way to see where any of it actually was.

Approach

A public gateway where an opportunity is a structured, searchable record rather than a document. Filtering across industry, sector, commodity and country, GIS dashboards over the assets, and investor onboarding behind it.

Outcome

Live and publicly reachable, presenting bankable opportunities across the continent in one place — with the geography attached rather than described.

Problem

Case records, station deployment and incident reporting lived in separate systems with no spatial view, so nobody could see where anything was happening until after it had.

Approach

One operational picture: a layer-managed map with heat mapping over station, settlement, hydrology and transport layers, alongside records search, deployment planning and structured incident reporting.

Outcome

Delivered and in use. The screenshots show the demo environment — identifiers read DEMO-NID-001 and sentences read 'synthetic value for testing only' because that is exactly what the demo data is.

Basemap © OpenStreetMap contributors

Problem

Two problems, one authority. Department heads had no shared way to track KPIs, so performance evaluation was manual and retrospective. Separately, every licensed telecoms operator filed its statutory returns by hand, which made the regulator's own reporting only as timely as its slowest submission.

Approach

Three interconnected systems, built and deployed solo. A centralised KPI and performance monitoring platform for the authority's own departments, and the Online Data Collection system — the portal where every operator logs in and submits its monthly, quarterly, bi-annual and annual returns directly.

Outcome

Three systems in active production at the regulator. Operator returns now arrive through one portal on a known schedule, rather than as attachments chased by email.

Problem

Handing someone a 19 GB orthomosaic is not a file transfer problem, it is a software problem. The recipient needs QGIS, a server, or both — so in practice the survey never reaches the person who needed to look at it.

Approach

A headless Python library plus a thin QGIS dock that packs a project or an orthophoto — ECW and JP2 included — into one PMTiles archive with a MapLibre GL viewer that opens from the filesystem. GDAL is driven by subprocess rather than shipping a C++ tiler, and pmtiles is vendored into the plugin zip, so Windows installs cleanly.

Outcome

v0.1 shipped with an installable zip. The style translator never imports PyQGIS, so it tests in about a tenth of a second — which is why the suite is worth running.

Problem

An inherited ward layer carried population attributes that looked plausible and were entirely fabricated by a bad join — the value was a function of ward number alone.

Approach

Treated the document's own subtotals as a test suite. Rebuilt the join on a geometry-derived crosswalk, recomputed area in an equal-area projection rather than in degrees, and reconciled every ward against the published census tables before projecting forward.

Outcome

46 distinct population values had been broadcast across 1,981 rows. After the repair, 1,979 of 1,981 wards matched the census — including one ward filed under a province 150 km from where its geometry sits.

Problem

Rural district councils held climate, agriculture, hydrology and infrastructure data in siloed formats, which blocked any coordinated drought or flood preparedness at district level.

Approach

Centralised geospatial repositories on PostgreSQL/PostGIS with layers published through GeoServer, deployed across more than ten councils — then trained council staff to run them without outside support.

Outcome

The training is the part that mattered. The councils still operate these without external support, which is the only definition of a successful deployment in that setting.

Problem

Large parts of rural Zimbabwe are thinly represented in open spatial data, which limits navigation, planning and humanitarian response exactly where those matter most.

Approach

Ongoing digitisation of rural infrastructure — roads, schools, clinics — validation of existing data, and participation in humanitarian mapping campaigns.

Outcome

Open data that other people's systems can be built on.