Flagship case study

Atlas NHD Hazard Disclosure Platform

Atlas Geotech LLC · Full-Stack Developer · Feb 2026–present

California statutory hazard disclosure, automated end to end — from raw government geodata to a legally-formatted PDF in a homebuyer's inbox.

Statewide

every residential sale in California

End to end

government geodata to delivered report

4 services

one automated pipeline

Front-end lead

on the hazard analysis app

The domain

Correctness is the product

Every residential property sale in California legally requires a Natural Hazard Disclosure. Producing one means checking a specific parcel against dozens of state and federal hazard datasets — flood, fire severity, seismic, landslide, liquefaction, dam inundation, airport noise — and emitting a document in a statutorily prescribed format.

That constraint shapes every engineering decision. A slow report is an inconvenience; a wrong one is legal liability for the disclosure provider. So the interesting problems here are not about scale — they are about determinism, provenance, and never silently degrading.

Stack

Python/FastAPI determination engine over PostGIS and GeoServer, Celery for async report orders, Prefect for dataset refresh, WeasyPrint for PDF rendering, Next.js customer portal, Terraform-defined AWS infrastructure.

PythonFastAPIPostGISGeoServerCeleryPrefectWeasyPrintNext.jsTypeScriptTerraformAWS ECS

Architecture

Four services, one pipeline

Government geodata enters at the top and leaves as a delivered PDF at the bottom. Each tier owns one responsibility and talks to its neighbours over a versioned HTTP contract.

01

Atlas SDI

Spatial data infrastructure

PostGIS, GeoServer, and GeoNode holding state and federal hazard layers. Prefect flows keep datasets current; a registry tracks currency and alerts on drift.

02

geocoding-service

Determination and rendering engine

FastAPI service that resolves an address to a parcel and APN, runs the hazard determinations, and renders the result. Covers the full range of disclosure products, with a queue for asynchronous orders.

03

portal-admin

Orders, identity, entitlements

Order lifecycle, JWT issuance for the customer API, per-user report access limits, and email delivery. Polls the SDI for report status.

04

portal-atlas / atlasnhd.com

Customer-facing portal

Next.js portal for address search, report selection, checkout, and PDF delivery — plus the public marketing site on S3 + CloudFront with OIDC-authenticated deploys.

Engineering decisions

Four problems worth writing down

Concurrency control under CPU-bound load

The problem

A single address lookup fanned out into nine fire-and-forget warmup tasks, each eventually submitting to a WeasyPrint process pool. Across three uvicorn workers that meant up to twelve rendering children, PID accumulation to 80, and workers dying in a loop.

What I did

Bounded the fan-out with a per-worker asyncio semaphore, then removed the redundant work underneath it: a shared httpx client with connection pooling, an LRU basemap cache with async-lock dedup so concurrent requests for the same tile collapse into one fetch, and rendering moved onto a ProcessPoolExecutor with proper lifespan shutdown hooks.

Zero-downtime data promotion

The problem

Hazard datasets are refreshed from state and federal sources on their own schedules. Swapping a live table mid-transaction risks serving a half-loaded layer into a legally binding document.

What I did

A promotion tool that stages the new table, then atomically swaps it — carrying sequences the live table still depends on, and applying additive schema changes behind an explicit flag rather than silently. Orchestrated with Prefect flows promoting from on-prem NAS storage up to AWS.

Graceful degradation on third-party outage

The problem

Flood determinations depend on FEMA's National Flood Hazard Layer. When that service is unreachable, report generation stops — and a disclosure that cannot be produced blocks a property sale.

What I did

Failover to a locally held NFHL copy when FEMA is unreachable, so an upstream government outage degrades freshness rather than taking the pipeline down.

Spec-driven delivery

The problem

Statutory report content is defined by legal templates, not by developer intuition. Getting a checkbox or a citation wrong is a compliance failure, and a rewrite cycle is expensive.

What I did

Seventeen design specs and ten implementation plans written and reviewed before the code. Report templates are pinned by tests that assert on the rendered markup contract — including an explicit escaping contract for the cover page, so a formatting regression fails a test rather than reaching a customer.

Results

  • The full range of statutory disclosure products in production — residential, commercial, tax, tenancy, fire severity, and more.
  • Report content locked down by automated checks, so a formatting change cannot quietly alter a legally binding document.
  • Report generation moved off the request path onto a queue, so a slow dataset no longer blocks a customer's order.
  • Infrastructure defined as code on AWS, with access permissions tightened to least privilege after a security review.

My role

Primary developer on the determination and reporting pipeline, and sole developer of the customer-facing portal.

Scope covered report generation, the data refresh pipeline, AWS infrastructure, the customer-facing portal, and the public site — plus security review of adjacent work, including a stored XSS finding in a colleague's feature written up and handed over with a suggested fix.

AtlasNHD.com — public launch in progress.

Have a system like this to build?

Regulated domains, messy third-party data, and pipelines that cannot silently fail — that is the work I do best.

Book a Systems Review