Contract
Available for a three-to-six-month contract.
Senior TypeScript, Next.js and Postgres. I build and run production systems where money moves, and I have done since 2012 — e-commerce backends including work on Dyson’s store, then a booking-and-payments platform I designed and kept running for four years as a contractor. Most useful where the hard part is the system rather than the screen, and where I would be reviewing other people’s code as well as writing my own.
The short version
- Role
- Senior full-stack engineer — TypeScript, Next.js, Node, Postgres.
- Length
- Three to six months, renewable.
- Engagement
- Through my own UK limited company, incorporated on offer. Outside IR35 preferred; umbrella for inside-IR35 work.
- Day rate
- On request.
- Availability
- UK-based and available now. Currently on a temporary working trip abroad, with a daily overlap from about 13:00 UK and flexibility outside it. Back in the UK early in the engagement, and on site from then.
- Based
- Bristol, UK. Remote-first — everything on this site was built and operated that way.
- Right to work
- British citizen. No visa or sponsorship needed in the UK.
- Cover
- Professional indemnity and public liability in place before the start date.
This is a return, not a first attempt.
The part of the record that matters to a contract client is the part furthest from the top of my CV, so it is here rather than at the bottom of a page about me.
I have contracted before, for four years.
Two concurrent engagements in Bristol, both on day rate, both direct with the client: a booking-and-payments platform for a chiropractic clinic, and backend work at a venture-brand agency. Both ended in March 2020. What is new this time is the machinery rather than the work — I ran those self-employed, and a limited company is what the market runs on now.
I kept one client for four years.
I designed and built the clinic’s scheduling and card processing in 2016 and then operated it until 2020, while the practice grew into it — including the reporting they actually ran the business on. Contract clients buy renewal rather than novelty, and that is the most useful thing I can tell you about how an engagement with me tends to go.
Agency delivery discipline.
Three years of fixed launch dates, client engineering teams and other people’s codebases — high-traffic stores processing real transactions and real customer data. An unglamorous place to learn that reliability is a feature, and the working environment of most contracts.
The thread is money.
Transactions and customer data at scale, then booking and payments, and now booking and payments on two rails with payouts that cross a border. One class of problem, worked since 2012, where being wrong has always cost somebody their actual money rather than a failed build.
The six years off
I stopped in March 2020 and did not work in software again until March 2026. Both contracts had ended and I did not go looking for more: I could afford not to, and after eight years of agency e-commerce I wanted to find out what else there was. That turned into six years of travelling.
I am not going to dress it up as a sabbatical with a thesis attached. I stopped because I wanted to and could, and I came back for the same reason. What brought me back was coding agents — the discovery that the bottleneck had moved, not the novelty. Everything on this site was built after March 2026.
Where I am most useful, and where I am not.
Ruling out the wrong engagement early is worth more to both of us than a call that discovers it in week two.
A good fit
- Systems with real consequences — payments, scheduling, integrations, anything where a wrong state costs money or time rather than a rebuild.
- Teams who want the delivery pipeline as well as the code: a merge gate that has to be green, a coverage floor that only ratchets upward, migration-drift and deployment checks, and decision records that say why each exists.
- Reviewing other people’s code. Everything since March 2026 has been built by a team of one, and this is the part of a team I actually miss.
- Teams already building with agents, or about to be. I have run production systems that way since March and measured what it did.
Not a good fit
- Design-led frontend work. I work across the stack and write interfaces when the interface is what is in the way, but I am not the person to hand a design system to.
- PHP and Magento. Eight years of it are in my history and none of it is on offer — the stack I want to be held to is the one I have shipped this year.
- A synchronous culture with a 09:30 stand-up, until I am back in the UK. The overlap starts about 13:00 and that is a real constraint rather than a soft one. An asynchronous-friendly team will not notice it; a team that lives in the morning will.
What you can look at
Three of these are open to a stranger with no introduction from me, which is the only reason they are worth listing.
- AgendaProfe, live ↗
- Booking, package purchases, subscriptions, payouts that cross a border, and live classes with translated captions. In production since May 2026, carrying real bookings and real money. You can open a teacher’s public booking page and walk the checkout without credentials. The engineering write-up has the trade-offs and the mistakes intact.
- groundtruth ↗
- A small open-source CLI and GitHub Action that fails CI when an agent-context file makes a claim the repository no longer supports. MIT, on npm, and it gates this site’s own pull requests. It exists because auditing my own context layer turned up claims that had quietly gone false.
- This site’s source ↗
- Static Astro, no client framework, four required CI jobs including axe and Lighthouse budgets. Small, but it is the one thing here you can read end to end in an afternoon and judge for yourself.
- The code you cannot see
- AgendaProfe is private and stays private — it holds real teachers’ and students’ bookings, messages and payment records, so there is no browse-the-repository route into it and I would not offer one. I am happy to walk through any of it on a call: schema, failure modes, the decision log, the parts that went wrong first.
The next step is twenty minutes.
If you have a role, tell me what the system does and where it hurts, and I will tell you straight away whether I am the right person for it. If you are a recruiter, everything above is what you need for a submission — ask me for the rest.
Separately, and with no role behind it: if your team builds with coding agents, I am still interested in what that actually changes inside a real engineering organization. Twenty minutes comparing notes is welcome either way.