Ten years ago I wrote Zero to development of an idea, about going from idea to running code before the enthusiasm wears off. The premise was one sentence: the faster I can get an idea off the ground, the more likely I am to continue it.
That sentence has aged perfectly. Almost every other sentence in that post has aged like milk. The 2016 bootstrap was a FlorxLabs server with wildcard subdomain DNS, an Apache rewrite rule, and Sublime Text uploading to the server on every CTRL+S - state of the art for me at the time, and a museum piece now.
So here’s the honest 2026 version: I don’t really bootstrap projects at a computer any more.
The new bootstrap
My last two side projects were built almost entirely from my phone, using Claude Code running in cloud containers. The loop looks like this:
- An idea (or a bug, or a tweak) occurs to me - on the sofa, on a train, mid-run.
- I open Claude Code on my phone and describe what I want. A container spins up in the cloud with the repo checked out - I don’t host anything, and nothing runs on the phone itself.
- It does the work and opens a pull request, and I get a preview deployment on its own URL.
- I review the diff and poke at the preview - still on the phone - then merge, and it’s in “production”.
The laptop is now for the genuinely gnarly stuff. Everything else happens in the gaps in the day, on a device I was already carrying. In 2016 I was proud of how fast I could get an idea onto a server at a desk. The 2026 equivalent is that there is no desk.
Well - almost. I’m still a millennial who wants a laptop for booking tickets and anything else that actually matters. That bit hasn’t shifted an inch. Getting an idea running just isn’t on the list any more.
Two recent things I built from my pocket
marathon.florxlabs.com exists because I’m training for a marathon, and I know myself well enough to know I need accountability infrastructure. It’s the whole thing - the site, the training plan itself, and an iPhone app nobody but me will ever run. That one exists purely to prise every last detail of my runs and swims out of HealthKit. The plan itself gets rewritten by Claude after every workout. There’s something pleasingly circular about maintaining the tracker during the training: notice a gap in it on a long run, stretch first, then describe the fix from the sofa and review the PR while my legs recover.
delayometer.london exists because “minor delays” on the Tube is doing a lot of heavy lifting as a phrase, and I wanted to measure what’s actually going on using the public data rather than the status board’s vibes. Tube, Elizabeth line and DLR. Same story: built up in dozens of small phone-sized sessions, reviewed and shipped from wherever I happened to be standing.
What actually changed
Typing was never the bottleneck - I could always type. The bottleneck was that side projects live or die on momentum, and momentum dies in the gap between having a thought and being somewhere you can act on it. The 2016 post attacked that gap with a wildcard DNS trick. The 2026 answer removes the gap entirely: the computer comes to you.
The stack changed underneath all of it too. PHP and MySQL on a box I kept alive myself, now TypeScript on Vercel, deploying straight from the repo on every push, and serverless Postgres from Neon whenever something needs a database. TypeScript won on the same grounds the old setup did - it’s the fastest way I know to get from nothing to a thing that runs.
The other change is where my effort goes. When the writing of code is cheap, the reviewing of it is suddenly the job - deciding what to build, judging whether the plan that comes back is any good, and actually reading the diffs. I wrote about why code reviews matter in 2018, when the author was always a colleague. That post is due a sequel now the author is usually a machine and the reviewer is usually me, on a phone. Another day.
I used to think this only worked for small, well-described chunks of work. It goes a lot further than that. I’ll quite often set Claude Fable off on a long, high-effort planning run over a whole idea from scratch - monetisation, market research, who else is already doing it, the lot! - and have it break the result down into tasks I can hand to a /goal run. You’re still the product manager and the last line of defence, though. The workflow makes it easier than ever to ship something, including something mediocre, so the judgement matters more, not less.
See you in 2036
The 2016 post had me happily describing my little dev box. It’s long gone, and its 2026 replacement is a container that exists for minutes at a time and is thrown away afterwards. I once wrote about shutting dev down at night to save money and prove the rebuild worked - this is that idea taken to its logical conclusion, where the environment barely exists at all.
The premise survives, though: reduce the friction between idea and running code, and more ideas become running code. In 2016 that meant a pre-configured server. In 2026 it means the phone in my pocket. I can’t begin to guess what it means in 2036, except that I assume I’ll get to write this post again. Same time in ten years?