Handed over, and it still runs
An organisation with a large member network hired me to build their platform to a spec. I built it, rehearsed the cutover twice, ran the real one clean, and handed the whole thing over in writing. Their team runs it without me. That's the story.
They're not named here because I choose not to offer past clients as references. Once work is handed over, a client owes me nothing, not even their name on my website. What I can show is the engineering. So that's what this page is: the numbers from the delivered repository, each one a chip with its method and the date it was counted. It's written for a technical reader, so if you have one, hand them this page. If you don't, the last sentence of each card says what it means for you as the owner, and those are the only sentences you need.
Six things a technical reviewer can check
An API their team runs without me
35 route files carrying 52 handlers, and 15 admin pages their own people use day to day. Nobody raises a ticket to me to change a record. That was the brief.
Built as if the app will have a bug one day
18 tables, 6 of them under row-level security, split across two database roles. 5 negative tests connect as the public role and each one expects permission denied. So even if the application has a bug, the public role cannot read personal data.
Signed webhooks, both directions
4 external platforms connected by signed webhooks. 6 modules do HMAC verification with timing-safe comparison, and an unconfigured secret fails closed: the request is refused. Replay protection is two layers, a time window plus a database dedup, so it holds through cold starts.
The cutover was rehearsed until it was boring
2 full rehearsals before production. The second caught 5 defects the first could not. By the real run, 722 images moved with 0 errors and 0 rows left on the old host. Boring is what you want on cutover day.
It checks itself while nobody watches
4 scheduled automations run unattended, including a daily security scan with 9 checks that goes red on regression. If someone weakens a permission six months from now, the scan says so the next morning.
They can leave me and keep everything
209 source files catalogued in a 52 KB handover inventory, 22 environment variables documented and grouped by service, 12 maintenance scripts each with a one-line purpose. Every value you'd need to change to run it in your own environment is named.
Two roles, one wall
What this means for your handover
I build to a blunt test: could your team run this if I disappeared tomorrow? For this client the answer is yes, and it's written down. The inventory names every value you'd change. The scripts say what they're for. The daily scan tells on the system if anything weakens later.
The same standard applies to you. You own the code from day one. The cutover gets rehearsed before it's real. And if you ever want to leave me, you can, with everything. I'd rather earn the next engagement than lock you into this one.