Software Engineering - How I approach building software
The principles, patterns, and ways of working that guide how I design and build systems.
Product-first
Engineering decisions serve the product, not the other way around. The right architecture is one that ships value quickly and holds up over time - not the most technically impressive one.
Domain-driven design
Modelling the problem domain clearly before writing code produces systems that are easier to reason about, extend, and hand over. Ubiquitous language, bounded contexts, and explicit domain models are defaults, not afterthoughts.
Type safety as communication
TypeScript and strong typing in every language I use. Types are not just a safety net - they communicate intent, constrain misuse, and make refactoring predictable. The compiler is the first reviewer.
AI-augmented workflow
AI tooling is embedded into how I work, not bolted on. Cursor for editing, Claude for reasoning through architecture and code review, n8n for automating workflow - used deliberately to go further, not just faster.
Quality is a delivery concern
Reliability, maintainability, observability, and clean ownership are part of shipping the work. They are not extras reserved for a later hardening phase.
System design starts with fit
The right architecture is the one that fits the problem, the team, and the pace of change. I bias toward decisions that stay legible as the system grows.
Agentic workflows need standards
AI-assisted and agentic development only compounds value when the surrounding system is structured: clear specs, clear ownership, reviewable code, and explicit architectural constraints.
Hands-on technical leadership
I prefer staying close to implementation while shaping direction. Architecture, delivery process, and team interfaces all improve when the feedback loop stays short.
Recent work
Luma Learn is a recent example of what sustained investment in spec-driven delivery and operational standards produces when combined with agentic development workflows.
Re-architecting for scale, resilience, and operational clarity under delivery pressure — maintaining quality and alignment throughout.
Read the case studyStandards and methodology, documented
Domain modelling, documentation standards, architecture patterns, and context/spec-driven delivery are documented rather than left implicit.
Read the docs