Why I kept this part boring.

Most of the projects I build have one genuinely new idea in them: an agent that researches a resale listing, a pipeline that writes screenplay coverage, a scheduler that runs coding agents while I sleep. Everything around that idea, I try very hard to keep boring.

Postgres, almost always

Marketplace Studio, NUYU, Fulcrum, Minute Marketing: they all sit on Postgres. Not because it's exciting, but because I already know how it fails, how to back it up, how to restore it, and how to read its query plans at 1 a.m.

When a project needs a queue, the first answer is usually a table. NUYU uses pg-boss, and Marketplace Studio keeps its jobs in Postgres with cancel and retry. One database means one backup, one thing to monitor, and transactions that cover both "save the item" and "start the job." I'll reach for Redis or a dedicated broker when the numbers actually call for it, not before.

Deploys you can undo in one step

Marketplace Studio deploys by building a release into its own directory, flipping a symlink, and checking readiness. If the check fails, the symlink flips back. That's it. No orchestration platform, no blue-green dashboard, and rollback takes about a second.

NUYU's CI is similarly plain: a restricted SSH key, build on the server, run migrations in a controlled step, health-check, done. I can explain the whole thing in a paragraph, which means I can debug it in a paragraph too.

Boring is a budget decision

Every project gets a limited budget of novelty, measured in attention. If I spend it on a clever deploy system or a trendy database, I have less of it for the part that's actually new, the part users came for.

So the agent gets to be interesting. The pipeline gets to be interesting. The thing that stores the data, runs the jobs, and ships the code gets to be dull, well understood, and quietly reliable.

Nobody has ever thanked me for a boring deploy script. But nobody's ever been paged by one either.