About Me

The Journey

I wrote my first lines of code in 1982 in Portugal, building business applications for mainframe systems — COBOL, CICS, IMS, DB2. It was painstaking, precise work that taught me something I've never forgotten: software that handles real data for real organisations has no tolerance for carelessness. Every byte counted, every transaction had to be right.

In the late 1980s I moved to Australia, where I completed postgraduate studies at Swinburne Institute of Technology and then an MBA at RMIT in Melbourne, focusing on the strategic management of information technology. I returned to Portugal in 1994, carrying both the technical foundation from those early years and a broader understanding of how organisations actually use — and misuse — the systems built for them.

For the next decade and a half I worked across traditional IT and business systems. The pivot to geospatial technology came gradually, then all at once. Reading the scientific literature on the major structural challenges of the 21st century — demographic pressure against food supply, water scarcity and desertification, deforestation and wildfire dynamics, urban sprawl against territorial limits — I kept encountering the same instrument at the centre of the analytical work: GIS. Not as a mapping tool, but as the framework that makes it possible to prioritise, to compare, to act on problems that are fundamentally spatial in nature.

That realisation reoriented my work completely. Over the past eight years I've focused on building the kind of systems that make spatial intelligence operational — not research platforms or visualisation showcases, but working applications that organisations use daily to make decisions grounded in territorial reality.

Academic Qualifications

How I Work

• Open-source, always
  Every system I build runs on open-source infrastructure — PostGIS, QGIS, Django, Python, Docker. No vendor lock-in, no licence costs, no dependency on a company's roadmap. The client owns the stack.
• The problem before the technology
  The choice of tools follows from the operational reality, not the other way around. A working system that fits the organisation is worth more than an architecturally elegant one that nobody maintains.
• Delivery and documentation together
  A system delivered without documentation is a system the client can't maintain. Migration scripts, runbooks, and data dictionaries are part of every deliverable.
• Minimum viable infrastructure
  A single well-configured VPS handles most real workloads. Complexity is introduced only when the problem genuinely requires it — not to make the architecture look impressive.

Working with AI

I use large language models as a structural part of my workflow — not as a search engine substitute or a writing aid, but as an execution layer for an architect who thinks in systems.

For most of my career I could design solutions that exceeded what I could build alone in a reasonable timeframe. The gap between conception and delivery was a practical constraint, not a technical one: there were only so many hours, and some implementation tasks demanded specialists I did not have access to as a solo consultant.

That constraint has largely disappeared. I now use Claude (Anthropic) as a collaborative technical partner across the full stack — from Django back-end logic and PostGIS query optimisation to front-end components, Docker configurations, and deployment automation. The model handles implementation detail at a pace and breadth that would otherwise require a small team; I handle architecture, requirements, data modelling, and the decisions that require understanding of the actual operational context.

The result is a material increase in what I can deliver — in scope, in speed, and in the complexity of systems I can sustain as a single practitioner. Every project currently listed on this site was built with this approach.

I am precise about what this means and what it does not. AI does not replace engineering judgement. It accelerates the translation of that judgement into working code — provided the person directing it understands the problem deeply enough to know when the output is correct, when it is plausible but wrong, and when the question itself needs to be reformulated.