Backend engineer / European space sector

I build geospatial data systems that stay reliable without microservice sprawl.

FastAPI and PostgreSQL/PostGIS, OGC services, satellite ground-segment tooling, and Postgres-native queue and job patterns. I work across the stack with Angular, React, and .NET when a project needs it.

Selected work

Public artifacts and live demos. Confidential work is described as anonymized case studies.

Interactive map ->

apsis

Shipped

Satellite pass-prediction backend on real CelesTrak orbital data (TLE): upcoming visible passes for a ground station and the ground track as GeoJSON. Postgres-native scheduled jobs and a transactional outbox (LISTEN/NOTIFY + SKIP LOCKED), no broker; PostGIS for the geometry.

  • Python
  • FastAPI
  • PostgreSQL
  • PostGIS
  • skyfield
  • OSS

On the horizon

geo-hazard

Planned

Natural-hazard spatial API focused on the Iberian Peninsula, over open European data (Copernicus EFFIS fires, EFAS floods, IGN earthquakes, AEMET warnings): bbox and radius queries, fire clustering, and spatial joins. The analytical, open-data counterpart to apsis.

  • PostGIS
  • Copernicus
  • DuckDB
  • FastAPI
2026

Product ownership

Planned

Anonymized case study (coming): owning a production FastAPI/PostgreSQL SaaS end to end - architecture, delivery cadence and product decisions, not just code.

  • FastAPI
  • PostgreSQL
  • Product
  • SaaS
2026

How I build

Reach for the simplest thing that holds under load. I have run queues, jobs, and schedulers on plain PostgreSQL instead of adding a broker, and shipped complex systems without microservice overhead. The right answer is usually fewer moving parts, not more.