Philosophy

Beyond Forms

Forms create or change entities. They never define them.

I don't build personal or organisational software as a collection of static pages and one-off forms. Every meaningful concept, e.g. a project, an article, a request, a section of this very page, is modelled as an entity with an identity, a structure, and a lifecycle. Pages are only views of those entities; forms are only mechanisms that create or change them.

That distinction is the foundation the rest of this Philosophy page builds on.

Business Before Technology

Technology choices follow from the problem, never the other way round.

Before reaching for a framework, a database or a cloud service, I want to understand what the business or the person actually needs, what already exists, and what a solution has to be true to in order to hold up over time.

Knowledge-First Thinking

Knowledge is the source. Every experience is a projection of it.

Whether it is project, a job or a course. I invest in durable, transferable understanding (Linux, networking, databases, software delivery, system architecture) over tool-specific shortcuts, because foundations keep paying off long after any particular tool has been replaced.

Open-Source Engineering

Build systems others can understand.

My engineering mindset is built on open, inspectable tools such as Linux, Python, PostgreSQL, Git, not simply because they are open source, but because they encourage understanding instead of abstraction. Combined with automation and CI/CD, they help create systems that are transparent, reproducible and maintainable by people other than their original authors.

Systems Thinking

Everything meaningful is a system before it becomes software.

I see a website, a platform or an organisation as a system of entities with structure, ownership, status, history, and a lifecycle, not as a pile of pages or a single form. That perspective shapes how I design internal applications, data platforms, DevOps workflows, and learning systems.

Long-Term Engineering

Good engineering is measured in years, not releases.

I optimise for systems that are still legible and changeable in three years, not just for shipping the next feature. That means favouring explicit lifecycles over implicit state, reuse over duplication, and documentation of why over documentation of what - the same standard this platform's own architecture is held to.