20+ years building
web platforms, and
the machines under them.
From server management to containers and Kubernetes, databases, backends, and the interface people actually touch. klarsmith is my studio — you get an engineer who carries a system from bare metal to the screen and keeps it running.
Four things, and the seams between them.
Most people you can hire own one layer and hand the rest off. The handoff is where projects go wrong. I don't have one.
Infrastructure & platforms
Bare metal, virtualisation, networks, Kubernetes, CI/CD, backups that have actually been restored from. Designed to be handed over and run by you — or kept running by me.
Backends & data
APIs, integrations, databases modelled for how they'll really be queried. PHP, Python, Go, Node — picked for the problem in front of us, not for my CV.
Websites & interfaces
From a marketing site that has to load fast on a phone in a tunnel, to an internal tool somebody stares at for eight hours a day. Built to be maintained by whoever comes next.
Taking over what's already there
The unloved server nobody wants to touch. The site that goes down every Monday. I'll tell you plainly what's wrong, what it costs to fix, and what you can safely leave alone.
Twenty years, laid down in layers.
Nobody starts at the top. I've worked every one of these in production, and each one is still there under whatever I build for you now.
I don't rent the platform my clients run on. I built it.
Client work doesn't sit on a shared host hoping for the best — it runs on infrastructure I designed, operate and get paged for. It isn't the product; it's the standard I hold my own work to, and the reason I can say what I say above with a straight face.
Measured, not estimated. Updated Sep 2026.
It started as curiosity, and that's still the useful part.
This was a hobby long before it was a job. I've been taking systems apart since I was a teenager, and twenty-six years on I still rebuild my own infrastructure on weekends nobody is paying for.
That isn't a personality note — it's the thing you're actually hiring. Someone who reads the changelog before the upgrade is someone whose upgrade doesn't take your site down at four in the afternoon. Someone who wants to see the layer underneath is someone who finds the real cause instead of restarting the server and hoping. Curiosity is what turns twenty years into judgement rather than twenty years of habit.
So when something does break, I'm not irritated by it. I want to know why — and you get the answer in a sentence you can repeat to your own people.
What it's like to work with me
You brief the engineer who builds it — there is nobody in between, and nothing gets lost on the way. Estimates I stand behind. Plain language instead of ticket-speak. And a system you could hand to somebody else tomorrow, because that's the only kind worth building.
What are you building — or what broke?
Either is a good first email. Tell me roughly what you've got and what you need it to do. I read them myself and reply within a working day.