There’s a particular kind of satisfaction in building something you can trust. Not trust in the sense that it won’t break — everything breaks eventually — but trust in the sense that when it does break, you understand why, and fixing it doesn’t require appealing to a service someone else controls.
I’ve been thinking about this a lot lately, mostly because I keep running into the same friction: I build something useful, come back to it six months later, and it’s half-broken. Some API changed. A dependency got deprecated. The free tier got discontinued.
The core problem
Most software is brittle in a way we’ve just accepted as normal. We build on top of layers we don’t understand, and we accept that breakage is someone else’s job to fix.
The offline-first movement — building apps that work without a network connection and sync when one is available — is interesting to me not just as a technical pattern, but as a philosophy. It forces you to think about what your app actually needs versus what it’s borrowed from somewhere else.
What I’m trying instead
For personal tools, I’ve started defaulting to:
- Flat files over databases when the data is simple
- Local-first data that syncs rather than lives in the cloud
- Dependencies I can vendor and freeze
It’s slower to start. But the things I’ve built this way still work years later without maintenance.
The goal isn’t to avoid all dependencies. It’s to be honest about which ones you’re betting on.
None of this is new thinking. It’s basically just: don’t build on sand if you can help it. But it’s worth saying again, because the default for most web development still pulls hard in the other direction.