CAPABILITIES
I split the work of building software into four areas. Under each one there are links to the projects that prove it — not claims, but decisions you can read.
The real work in an interface is not writing components but deciding how many faces a system has: a public site, a customer account, an operations panel and a field user can live in one codebase but should not share one shell. In a multilingual product, language is not a translation file — it is URL design.
A write path is only as reliable as what happens when it is called twice. Repeated requests, half-finished payments and two simultaneous writes are ordinary events. So I put authorisation and validation in a shared layer rather than per endpoint — and where possible move them out of the app and closer to the data.
The schema outlives everything else: code changes, data stays. Where a rule sits is therefore the architectural decision itself — while a conflict guard lives in the application, every new write path has to rebuild it. Never using floats for money belongs to the same discipline.
Delivery does not end with a deploy command: you need a mechanism showing that what shipped is correct and stays correct. Build gates are the cheapest form — content that breaks the schema or a missing setting fails the build. After launch, I watch every project I run from a single table.
The two Laravel projects here belong to none of the four areas, deliberately. I do not choose PHP for new work today; these two ran between 2024 and 2025 as an education provider's internal portal and public site, and they stand as archive. What I carried out of them is not technology but two habits: that language is a matter of URL design in a multilingual site, and that a published address must never be silently lost.
Tell me what you want to build; I'll tell you up front how long it takes and where to start.