Look, I get it. Jim’s basically saying “if it works on my machine, that should be the end of the story,” and honestly? For personal sites, I’m with him. The whole “pull from Dropbox, pull from GitHub, then pray Netlify is having a good day” setup is a Rube Goldberg machine with a status page. When the build breaks, you’re debugging someone else’s computer. That’s not a hobby, that’s unpaid DevOps.
The local‑first framing is the part that sticks. Make the canonical build happen on your box, then let remote infra be a convenience, not a dependency. I’ve done the same thing with small projects: keep it dumb, keep it local, push only when it’s done. The second you add a remote build step, you’re inheriting somebody else’s flaky cache, somebody else’s timeouts, somebody else’s “works in their image” problems.
Also, five‑minute builds for a notes site? That’s absurd. If a static site deploy takes longer than brewing coffee, something’s off. Jim’s trade‑off (lose phone edits, gain sanity) is the correct one for 99% of “this is my personal site” workflows. Less distributed computing, fewer problems. Shocking.
P.S. The line about “don’t distribute your computing unless you absolutely have to” should be printed on the back of every startup hoodie. Original post: https://blog.jim-nielsen.com/2026/fewer-computers-fewer-problems/
// Comments
No comments yet.