If you've been asked whether this person is safe to work with, this is what you usually want to know. I've written it plainly, including what isn't sorted.
Everything I build runs on a single VPS I operate myself — not a serverless platform that changes its pricing, and not a hosting account I don't hold root on.
| Reverse proxy & TLS | Caddy, automatic certificates, separate per-project configuration |
|---|---|
| Application processes | PM2 for Node services, Docker Compose where full isolation is needed |
| Databases | PostgreSQL in Docker for anything substantial; SQLite where genuinely single-writer |
| Operating system | Linux, automatic security patching, SSH key access only |
If you'd rather everything ran on your own infrastructure, that works too — and for the long term it's often the better call.
The rule is the same across every project, and this is usually your first question:
| Application services | bind to 127.0.0.1, never to 0.0.0.0 on the host |
|---|---|
| Docker containers | ports mapped as 127.0.0.1:PORT, not opened publicly |
| The only public door | Caddy, on 80 and 443 |
| Firewall | enabled, with explicitly opened ports |
| Anything that can execute commands | authentication required, no exceptions |
| Secrets | in environment files on the server, never committed to git |
A service binding to 0.0.0.0 inside a container is correct and has to be that way — the restriction belongs in the port mapping, not the application code. I mention it because the distinction is a common source of confusion.
No manual step exists only in my head. Every project carries its own deploy command, recorded in its repository.
| Source of truth | git, on the server too — not only on my laptop |
|---|---|
| Release | rebuild the image, rather than copying files into a running container |
| Rollback | return to the previous commit and rebuild |
| Schema changes | recorded migration files, not pushing schema directly |
Copying files into a running container is faster, and I used to do it. The consequence was a container being recreated for an entirely unrelated reason, taking 15 fixes with it. That approach isn't used any more.
Having a backup file is not the same as having a backup. What I do is prove it:
| Frequency | daily database dumps, automated |
|---|---|
| Destination | off-server cloud storage, with rotation |
| Verification | the dump is downloaded and restored into a temporary database separate from production |
| Pass criteria | row counts on the main tables compared against production until they match |
Restores are tested into a separate container and never touch production. The test container is destroyed afterwards.
An automated check calls every URL and records the response code. The catalogue on this site reads that same result, including when it's bad.
As this was written, several projects I'd marked live were returning 502. They stay in the catalogue. Hiding them would make every other number on this site worthless.
This gets asked up front least often, and matters most.
| Code ownership | agreed in writing at the start, not at the end |
|---|---|
| Repository | can live in your own git organisation from the first commit |
| Documentation | README, architecture notes, and deploy steps written as part of the work |
| Handover | a session with your team, with enough written down to continue without me |
If this arrangement ends, your team has to be able to carry on. If they can't, my work wasn't finished.
This is usually the biggest technical objection, so here it is without hedging.
I read and take responsibility for every change that lands. If I don't understand a piece, it doesn't ship. Some of the hardest bugs in my case entries were found by reading code and system output, not by asking an AI to guess.
No, unless that's the actual feature and you've agreed to it. For AI features I keep what's sent to the minimum — on one project, personal information was deliberately kept out of prompts until there was explicit approval to include it.
Chosen per case — Anthropic, DeepSeek, or others — based on cost, quality, and where the data is allowed to live. For your work, that's a decision we make together at the start, not one I make alone.
That's a real risk, and the answer isn't a promise. It's code that reads sensibly, a recorded schema, sufficient documentation, and a handover that actually happens. Ask to see any repository before deciding.
This list exists so you don't have to discover it halfway through a project.
If your need is on this list, you'll hear it in the first conversation. For some of them I can still help with the front half — shaping it, building the first version, then handing it to the team or vendor better suited to carry it.