Technologies

The stack listed on the Resume is the what. This page is the why: the principles that decide what makes it onto a project, and the references that shaped those principles.

Approach → choices

Choices are pragmatic — what serves the data and the decision, not what is fashionable. A handful of principles do most of the work:

• Open standards over vendor lock-in. OGC, INSPIRE, GeoParquet, MapLibre over proprietary equivalents. Migrations and handovers are cheap when the format is portable; expensive when it is not.
• Columnar and cloud-native by default. Parquet for archive, DuckDB for in-process query, Iceberg/DuckLake for tabular catalogs at scale.
• Reproducible infrastructure. Builds are deterministic from source — parquet generators in Python, sources catalogued as code, deployment as object-bucket sync.
• Cost-transparent serving. Static content where possible. The portfolio site itself for example has no runtime backend; the bucket is the deployment target.

Architecture

A representative (yet simplified) ingest-to-serve pipeline that recurs across client engagements: Airflow orchestrating ephemeral container jobs, parquet as the staging format across layers, PostGIS as the serving store, with object storage as the spine. I've built every layer end-to-end, from ingest through to data analysis and customer engagement.

This site's own architecture

A different shape entirely — no Airflow, no PostGIS, no API. The data layer is a folder of parquet files; DuckDB executes every SQL query in every page at build time; Evidence emits a static SvelteKit site; a CRON job re-runs the build daily and rsyncs the output into an Object Storage bucket. Walk-through on How this site is built.

Bookmarks and influences

A curated set of references behind the choices above — open data registries, extraction and serving tooling, AI plumbing, and a couple of well-built sample sites worth looking at.