SmartSustain
An Innovate UK funded Python and FastAPI platform that scores the sustainability of housing development sites, used by planning assessors across five West Yorkshire councils — backend, geospatial data model, scoring engine, AWS and the React frontend, all mine.
700+
sites scored
5
councils served
~70%
less manual reporting effort
// stack
// architecture
FastAPI backend with Pydantic boundaries and async background jobs · MongoDB with 2dsphere geospatial indexing · per-dataset Python loaders and domain processors with Pandas · weighted 4-pillar scoring engine with an explain endpoint · Redis caching over expensive spatial computations · LLM assistant grounded in scored data · automated PDF reporting · React + MapLibre GL frontend · AWS EC2/S3/CloudFront
// overview
Lead engineer on a platform that turns millions of records of government and open data into defensible sustainability scores for candidate housing sites. The whole backend is Python and FastAPI: async route handlers, Pydantic models on every request and response boundary, dependency-injected services and background tasks for the long-running jobs. Underneath it I designed the geospatial data model on MongoDB with 2dsphere indexing, and built the ETL layer — a loader per dataset and a domain processor per concern, with Pandas doing the heavy reshaping — unifying postcode, flood risk, air quality, road noise, deprivation, crime, EPC, transport and land registry data into queryable spatial collections. The hard requirement was not computing a number but defending it: every score decomposes back to its inputs, weights and provenance through an explain endpoint, and an LLM-backed assistant answers natural-language questions grounded in that decomposition rather than in free generation. I also provisioned and operated the full AWS deployment from first commit to production, and delivered the map-driven React frontend on top of my own APIs.
// what was built
- ·Innovate UK funded platform used by planning assessors across five West Yorkshire councils: Leeds, Bradford, Wakefield, Calderdale and Kirklees.
- ·Architected the entire backend in Python and FastAPI — async handlers, Pydantic request and response models, dependency-injected services, and background tasks for the long-running scoring and reporting jobs.
- ·Designed the geospatial data model on MongoDB with 2dsphere indexing, so nearest-neighbour lookups, polygon intersections and catchment queries execute in the database rather than in application code.
- ·Built the Python ETL layer as a loader per dataset plus a domain processor per concern, unifying millions of postcode and government dataset records into queryable spatial collections, with Pandas doing the reshaping.
- ·Engineered the scoring algorithm producing weighted 0–100 indices across environmental, economic, social and regulatory pillars for 700+ candidate sites, backed by live spatial queries over flood risk, road noise, air quality, deprivation, crime, EPC and transport data.
- ·Made every score defensible: an explain endpoint decomposes each calculation into its inputs, weights and per-metric contributions, which is what makes the output usable in a planning context rather than merely interesting.
- ·Built an LLM-backed assistant that answers natural-language questions about a site, grounded in that same decomposition, so an answer is always traceable to the data behind it.
- ·Missing data is flagged explicitly rather than silently scored as zero — an absent dataset degrades confidence in a visible way instead of quietly producing a wrong number.
- ·Optimised expensive spatial computations through geospatial indexing and a Redis caching layer, and automated planning-grade PDF report generation, cutting manual reporting effort by roughly 70%.
- ·Provisioned and operated the full AWS deployment (EC2, S3, CloudFront, TLS, CI/CD) from first commit to production.
- ·Delivered the map-driven React frontend — MapLibre GL, TanStack Query, Tailwind — consuming the same APIs I designed, so the contract between the two halves was never a negotiation.
System design
Drawn from the actual source: services, data ownership, message flow and failure paths. Drag to pan, scroll to zoom, or open any diagram fullscreen.
End-to-end platform architecture
Millions of government records flow through per-dataset loaders and domain processors into a MongoDB geospatial layer, out through a scoring engine, and into a map-driven interface used by planning assessors across five councils.
// engineering notes
The decisions worth talking through
The parts of this project where the interesting work was choosing between options, not writing the code.
The product was auditability, not the score
A planning assessor cannot act on a number they cannot defend at committee. That single constraint shaped the architecture: scoring had to be decomposable rather than a fitted model, weights had to be inspectable, provenance had to survive from the source dataset all the way to the PDF, and the LLM assistant had to be a reader of that structure rather than an independent source of claims.
Spatial queries are the cost centre
Nearly all of the latency in a site score comes from a handful of geospatial operations — nearest-neighbour lookups, polygon intersections, catchment queries. Indexing with 2dsphere and memoising results in Redis was targeted specifically at that layer, rather than caching whole API responses, so a score stays live and correct while the expensive geometry underneath it is reused.
Why FastAPI, and what Pydantic actually bought
The platform ingests messy third-party government data and emits numbers that end up in planning decisions, so the boundary is the place to be strict. Pydantic models on every request and response turned schema drift in a source dataset into a loud, located failure at ingest instead of a quietly wrong score three layers downstream — and FastAPI generating OpenAPI from those same models meant the React frontend and the backend never disagreed about a shape.