Most of your backend decisions don't matter yet

Sachin Pal wrote a piece called I Built a Full Stack App Using Just Prompts, and the first half of it is the most accurate description of side-project death I've read. He lists five things that kill his projects. Decision paralysis over which database. Auth turning into a two-day detour. File storage being more annoying than it looks. Local working and production not. Migrations against a database that already has data in it.

Every one of those is real. I've been paged for three of them.

He's a frontend engineer, and he's describing what the backend looks like from outside it. I've spent most of my career on the other side of that line, and I read the same list differently. Not because it's easier than he says. Because four of those five problems only exist after a decision that nobody required him to make.

That difference is worth writing down, because it's the thing you can't see from where he's standing and I couldn't see it either at his distance from it.

The question that dissolves most of them

Before you spend an afternoon on a decision, ask what it costs you to change your mind in six months.

That's the whole test. It sounds too simple to be useful. Run it on his list anyway.

Postgres or MySQL, for a side project with no users. Cost of being wrong: you rewrite some SQL, in a year, if the project is still alive. Most aren't. This is a thirty-second decision that people give forty-five minutes because comparison articles are written to be read, not to be decided from.

Which host for that database. Cost of being wrong: an export and an import, an afternoon, and you'll do it anyway when the free tier changes. Thirty seconds.

Auth. Cost of being wrong: someone else's account, and you find out from them rather than from your tests. This one is expensive and it fails late, which is the worst combination there is. So don't build it. Take whatever your framework or platform hands you and move on. Building session handling by hand in 2026 is not a rite of passage, it's just a way to own a security incident.

File storage. Cost of being wrong: swapping one S3-compatible client for another, because they're all S3-compatible. Thirty seconds, and the answer is whichever one your host already has.

That leaves migrations, which he's right about and which stays hard. Changing the shape of data that already exists is genuinely irreversible, it fails in production, and it fails on the rows you didn't think about. Give that one the afternoon. It's the only item on his list that earns one.

Four thirty-second decisions and one that matters. He spent two days.

The decision he skipped

Here's what I'd tell a junior engineer reading his list and recognising themselves in it.

Nothing in that piece asks whether the app needs accounts at all.

It's assumed on the first page, and then everything after it is the correct consequence of that assumption, suffered honestly. He needs users to log in, which means auth, which means a database, which means hosting, connection strings, environment variables, and a Stack Overflow answer from 2019. The chain is real. It just starts with a link nobody examined.

That's the pattern, and it doesn't stop at side projects. The decisions that cost you are not the ones you agonise over. They're the ones you never noticed you were making, because everybody makes them.

I've seen the expensive version of this. At a bank, operators moved reports between seven hundred branches by hand, every day, pasting credentials and paths out of a spreadsheet, because the tool had no batch mode. The fix was a loop and a config lookup. It sat there for years, not because it was hard, but because "this is how we move reports" was never a sentence anyone said out loud, so it was never a sentence anyone could disagree with.

Same thing here. "An app has accounts" isn't a decision until you say it as one.

What it looks like when you do ask

The site you're reading is the worked example, so let me be specific about what saying no bought.

It has no database, so there's no decision about which one and no migrations. There's no auth, so there's no session-or-token argument and no OAuth callback handling. There's no file upload, so there's no bucket, no CORS policy and no presigned URLs. Content is markdown files in git, which means the same files run on my laptop and on the server, which means the local-works-production-doesn't gap has nowhere to open up.

Five problems, four gone, and the remaining one never came up.

None of that is cleverness. It's a document I wrote before I started that says what this is not, and the discipline to not build the things on that list even when one of them would have taken five minutes. Especially then. Five-minute features are how the list gets long.

They're all coming later, incidentally. Analytics, a console, search. They land on a site that's already up and already read, which means I'll know what I actually need instead of guessing. That's the other half of the answer to decision paralysis. A decision you defer long enough usually gets made for you by evidence.

And then it was down anyway

I want to end on the part that no amount of good decisions covers, because I hit it four days ago.

The site went live over a weekend. The binary was correct, every test passed, the content parsed, the reverse proxy config was three lines and also correct. Then the certificate wouldn't issue. Both challenge types failed with the same message:

"3.109.166.86: Timeout during connect (likely firewall problem)"

Nothing in the repository was wrong. Nothing an agent could read was wrong. The answer was that "timeout during connect" and "connection refused" are different sentences, and the difference between them tells you whether something is listening and something else is dropping the packets. It was a security group in front of the machine, two ports, and a checkbox.

That's the part that doesn't come from prompting, and it isn't going to. It's not knowledge about a framework. It's the habit of reading the exact words of an error instead of the shape of it. You get that by being wrong in production and paying attention while you fix it.

So: make fewer decisions, defer the ones you can, and spend the time you save on being the person who can read the log.