Every project is different. The method barely moves.
A web project rarely fails on the technical side. It fails because nobody said early enough that we were heading the wrong way. Hence the way I work: short cycles, permanent access to what’s in progress, and regular check-ins rather than one big reveal at the end.
My job is as much about stepping back from what I’m asked for as it is about writing code. A technical decision is judged on what it will cost in three years, not on how modern it looks.
Most projects don’t start from a blank page. There’s a site running, content to carry over, tools already in place and working habits. I start by understanding all of that before suggesting we replace it.
All these years in the trade taught me the essentials: adapting to projects with nothing in common, framing a need before building it, keeping things simple where I can, and delivering work that holds up over time.
- 01
Scoping
We start from what you need, not from a feature list. Goals, constraints, whatever already exists, realistic deadlines. I also ask the questions nobody enjoys asking up front: who decides, who supplies the content, what happens if the schedule slips. By the end of this stage, we’re describing the same project in the same words, and the quote reflects exactly what we discussed.
- 02
Design
Site structure, user journeys, content architecture. An interface gets thought through before it gets drawn: information hierarchy, consistent components, usability on mobile as much as on a wide screen. Good UX goes unnoticed, you move through it without thinking. That same structure is what makes a site readable by search engines, conventional and generative alike. If you work with a designer, I build from their mockups and we stay in touch from start to finish. If not, I can take that part on as well.
- 03
Build
The bulk of the work. Front-end, back-end, connections to the tools you already use. I move through functional blocks, starting with whatever carries the most value, so you have something real in front of you early. You follow progress as it happens, and each piece of feedback is handled when you raise it.
- 04
Testing and launch
Browsers, mobiles, performance, accessibility, technical SEO and GEO: everything is checked before going into production. We test together on an environment identical to the final site, with your real content and your real use cases. Fixes happen before the switch, never after. A launch takes preparation.
- 05
Aftercare
Handover, documentation, then maintenance if you want it. I take the time to train the people who’ll be using it, and leave behind enough for anyone to work out how it all fits together six months later. The first few weeks after launch are usually when you find what nobody anticipated: I stay available for that. The goal doesn’t change: you should be able to do without me.
- Languages
- PHPJavaScriptTypeScriptHTMLCSS
- Front-end
- ReactVue.jsmodern CSSanimation
- Back-end
- SymfonyLaravelAdonisJSNode.js
- Data
- MySQLMariaDBPostgreSQLMongoDBRedis
- CMS
- WordPressWooCommerceKirbyPrestaShop
- Automation & AI
- n8nmodel APIsintegrationscustom scripts
- Standards
- accessibilityperformancetechnical SEO/GEOlean design
This list isn’t exhaustive. Tools get chosen around your project, your budget and what your team will be able to pick up afterwards. I adapt to what you need, not the other way round.
A question about the way I work? Happy to talk it through.
lehroj@pm.me