Web applications
Usually Next.js, React and TypeScript. Server-rendered, accessible, and quick on an average phone rather than only on a fast laptop.
Web development
Built properly the first time
Fullstack development by someone whose other job is finding bugs. I know what badly built software looks like from the inside, because I spend my working life taking it apart.
What I build
A whole application, or the piece you're missing
Plenty of this work is a defined slice: an API, a frontend, a feature someone needs finished.
Backend and APIs
Node.js services and REST APIs with sensible error handling and enough logging to work out what went wrong at three in the morning.
Frontend and design systems
Components built once and reused, so the fifth page looks like the first and adding the sixth doesn't mean starting over.
Integrations
Payment providers, booking systems, CRMs. The work is rarely the happy path; it's what happens when the other service is slow, down, or returns something unexpected.
Work on existing codebases
Picking up a project someone else started. Where it's worth it, I'll add tests around what's there before changing it, so you find out immediately if I break something.
Automated tests and CI
Tests that run on every merge. This is my main line of work, so it's built in from the start rather than promised and skipped.
Maintenance and small changes
Bug fixes, dependency updates and the steady trickle of small features. Useful if you have a site nobody currently looks after.
How it works
You see it working as it's built
Long projects go wrong quietly. Short cycles with something real to look at mean you find out early if we're building the wrong thing, while it's still cheap to change.
- 01
Scoping
We work out what you actually need, which is often smaller than the initial idea. I'll write down what's in and what isn't.
- 02
Approach and estimate
How I'd build it and what it costs. If something looks risky I'll say so here, not later.
- 03
Building
Work goes live to a test environment as it's finished, so you review real software rather than a status update.
- 04
Testing
The same testing I'd sell you on its own: regression, accessibility, error handling, and the paths that only break under load.
- 05
Handover
Deployed, documented and explained. Then I stay reachable for the first weeks of real traffic, which is when the real bugs appear.
Pricing
Clear scope, clear price
Projects start with a written scope and an estimate. What's included and what it costs are agreed before any work begins, so nothing on the invoice comes as a surprise.
Small build
Fixed priceA defined feature, a prototype, or a site that needs rebuilding.
- Agreed scope, fixed price
- Working software in a test environment
- Tests for what I built
- Handover notes
Project
Fixed priceA full application or a significant rebuild.
- Scoping, approach and estimate
- Regular reviews of working software
- Automated tests and CI
- Documentation and handover
- Support window after launch
Ongoing
Custom scopeA set number of hours a month for teams who need steady progress.
- Reserved hours each month
- Features and bug fixes
- Dependency and security updates
- Someone who already knows the codebase
Who this is for
Small teams and people with no team at all
That might be a whole build, or a defined piece of a bigger one. If what you need really takes a team of five, I'll tell you early.
Founders who need a first version
Fast enough to put in front of customers, built well enough that you're not rewriting it the month it starts working.
Teams with more roadmap than time
Hand me a well-defined slice and I'll deliver it to your standards, in your repo, through your review process.
Anyone with a site nobody maintains
The developer left, updates stopped, and every change now feels risky. Usually that means putting some tests around it first, then starting to move it forward again.
Got something you need built?
Tell me what you're trying to make and what's constraining you. I'll come back with how I'd build it and what it would take.
Start a project