Web Developer · United Kingdom
22 years of shipping the web. Still not extinct.
I'm Daniel Lambert — a freelance web developer who has been building for the web since 2004, from table layouts and dial-up through to Laravel and edge caching. I build things that work, keep working, and can still be changed three years later.
- Years in the industry
- 22+
- Building for the web
- Since 2004
- Case studies written up
- 0
- Asteroids dodged
- 1
About
I've watched the web change three or four times.
That is the useful part. Not the specific technologies — those keep moving — but knowing which decisions you regret in year three.
I started building websites in 2004, when layouts were made of tables, JavaScript was something you apologised for, and a surprising amount of the job was testing in a browser that no longer exists. I moved to standards-based CSS, then jQuery, then the first real PHP frameworks, then Laravel — and each time, the thing that mattered was not the tooling but whether the result could still be maintained after I left.
Somewhere in the middle of that I spent a stretch working outside the industry. It is the reason most of my back catalogue is offline: clients were acquired, businesses closed, domains lapsed, and nobody archives a trade portal. I can't hand you a list of live URLs. What I can do is show you exactly how each of those projects was reasoned about — which is the part that transfers anyway.
These days I work with Laravel and a deliberately small frontend stack. I take on new builds, rebuilds of things that have aged badly, and codebases somebody else abandoned. I am equally happy being the only developer or the one who gets a team unstuck.
Capabilities
What I'm actually good at
A short list I can stand behind, rather than a wall of logos.
Laravel & modern PHP
Application work in Laravel — domain modelling, queues, background jobs, APIs, and the boring reliability work that keeps them up. Comfortable in a codebase I did not write.
Frontend that holds up
Semantic HTML, CSS that does not fight you in a year, and only as much JavaScript as the job actually needs. Accessible and fast by default, not as a later pass.
Legacy rescue
Inherited systems with no tests, no docs, and no original author. I have spent a good part of twenty years making these safe to change again, without a big-bang rewrite.
How I work
No surprises, in either direction
Twenty years of client work distilled into four things I do on every project.
-
01
Understand the actual problem
The brief is rarely the problem. Before writing anything I want to see how the work happens today — the spreadsheet, the phone call, the workaround everyone has stopped noticing.
-
02
Agree what "done" means
Written scope, a fixed price or a clear day rate, and a defined first milestone. You should never be surprised by an invoice or a timeline.
-
03
Ship in visible slices
Working software on a staging URL early and often, so you are reacting to something real rather than approving a document.
-
04
Hand over properly
Tests, a runbook, and a walkthrough with whoever inherits it. My best projects are the ones that stopped needing me.
Got something that needs building — or rescuing?
Tell me what you are trying to do and I will tell you honestly whether I am the right person for it. No pitch deck, no discovery retainer.
Send me an enquiryUsually replies within one working day.