Deploying My Side Project at Midnight, I Got Stuck Somewhere I Never Saw Coming

It was past 10pm last Friday, and I was deploying code for a small system I've been building on the side. It's basically a personal "memory keeper": it takes the technical problems I run into, the calls I make, and the random ideas I have, and files them away automatically so I can pull them up later instead of re-explaining the background every single time. It has nothing to do with my day job — it's just a tool I've been tinkering with for myself.

When I was picking the stack, I did the math up front. For the AI model, I skipped the big overseas providers and went with a domestic one. For the database, I didn't spin up a new one — the server already had a PostgreSQL instance running, so I just hooked into that. The reasoning was simple: this is a side project, I'm paying for it out of my own pocket, and over the long run, API cost and whether the network actually stays reachable matter more than "which model is smartest." At the time, I thought I'd done the math pretty carefully.

Then deploy night came, and the money I'd saved showed up again under a different name.

The build got stuck first. I ran a fairly ordinary command on the server, pushed the build process into the background, and figured I'd just check back on it later. But the moment the command went out, the connection itself dropped — not the build failing, just the SSH session itself timing out somewhere between a few dozen and a few hundred seconds in, completely unrelated to the process running in the background. My first thought was the network was acting up; I tried twice and got the same result both times. I only got past it by switching to just sitting there in the foreground and waiting it out, with the timeout cranked way up. I still don't fully understand the mechanism behind this one — my best guess is the child process's stdio wasn't properly detached from the parent shell — but at least I know how to work around it now.

The second one was even more annoying. During the dependency-install step of the build, everything just froze for a full five minutes, not a single line of new output. My first instinct was "the server's network is acting up again." I probed the endpoint with curl, and it came back with a clean 200 — the network was fine. It took a while to figure out that a handful of packages just couldn't reach the default source every so often, not a full outage, more like a coin flip each time. I switched to a domestic mirror and reinstalled — done in under a minute.

Looking back, both of those problems were really just the other half of the savings math I'd done when picking the stack in the first place. Going with the domestic model and reusing the existing database was about the money I could see — subscription fees, API costs. But the time I burned that night — standing there at midnight staring at a stalled progress bar, guessing whether it was the network or my own code — never made it into that spreadsheet. What I saved wasn't money. It was moving the cost off the bill and onto my own evening.

That doesn't mean the stack choice was wrong — over the long run, the money really is saved. It just means that next time I pick a stack for one of my own projects, I'll ask myself one more question: how many of these deployment-day problems am I signing up to handle myself? Whether that hidden cost is actually worth it, I'll only know the next time I stand up something new and see whether I'm running into fewer of these. For now, all I can say is — it's worth keeping an eye on.