I build bespoke web applications, integrations and working prototypes for organisations that need real software fast — without the team, the budget or the timeline of a traditional dev shop.
Vibe coding — a term that's gained traction in 2024–2025 — usually means asking an A.I. to write you software, accepting whatever it produces, and shipping it without really understanding what you've shipped. When it works, it feels like magic. When it doesn't (and at scale, in production, or under load, it often doesn't), the failure modes are brutal: subtle data corruption, security holes nobody saw, code so A.I.-generated that no human on the team can debug it.
I do something different.
I bring twenty-plus years of writing software, leading architectures, and shipping production systems — including more than a hundred document-capture and automation solutions for NHS Trusts, banks, insurers and councils. A.I. is a tool I use the way a senior developer uses a fast junior team: to accelerate the typing, the boilerplate, the first-draft tests and the obvious refactors. Every architectural decision, every security boundary, every integration contract is mine. Every line of code that reaches production has been read and understood by a human who knows how to debug it later.
Internal tools, admin portals, customer-facing apps. The kind of build that used to need a four-person team and three months. I can usually scope one in a few days and ship the first usable version in two to four weeks.
The unsexy plumbing that connects your systems: API integrations, scheduled jobs, ETL pipelines, glue code between SaaS products. Frequently the highest-ROI work in any organisation, and the work nobody else wants to take on.
Working software in days, not months. For when you need to show stakeholders something real, validate an idea before you commit serious budget, or de-risk a build-vs-buy decision with actual code in front of you instead of a slide deck.
The mistake people make with A.I.-assisted development is treating the A.I. as the architect. It isn't, and shouldn't be. A.I. is excellent at the middle eighty per cent of building software — implementation, refactoring, generating tests, writing the obvious code, drafting documentation. It's bad at the hard twenty per cent: system design, integration boundaries, security, what to actually build, what failure modes matter, what's worth doing well and what isn't.
So the workflow looks like this:
It's faster than traditional development. It isn't faster because the A.I. is doing the thinking. It's faster because I'm not writing the boilerplate — and because you're seeing real software in days, not waiting for a big-bang reveal in months.
Three projects spanning the years before A.I.-assisted development was practical and the months since — the long-form delivery experience that the A.I.-assisted practice now amplifies.
A.I. didn't make me a developer. I've been one since 1981 — programming as a hobby through school, professionally since the early 2000s, then twenty years leading complex document capture and automation projects for some of the UK's largest organisations.
What A.I. changed is throughput. The same architectural instincts, the same code-review discipline, the same "will this still work in three years?" habits — but applied across more code, more projects, and more delivered software per week.
If you want vibe coding, there are cheaper places to get it. If you want software that ships, runs reliably, and someone can still debug in two years' time, this is what that looks like.
Send me a few lines about what you have in mind — even a fuzzy idea is fine. I'll reply with an honest read of what's involved, what isn't, and whether I'm the right person for it.