Picking a boring stack for a first client build

On my first proper client build I spent almost a week comparing frameworks before writing a line of real code. In the end I picked the most boring option I knew well, and I'd do it again. Here is how that decision went.

What I was tempted by

There was a newer framework everyone around me was excited about, plus a hosted database with a nice free tier and an edge setup that looked great in demos. None of it was bad. I just hadn't shipped anything real with any of it.

What I actually picked

A framework I had used for years, a plain Postgres database, a single server, and server rendered pages with a little JavaScript where it mattered. Nothing in that list would impress anyone reading a stack page.

Why boring won

The client cared about the thing working and being easy to change later. They did not care what it was built with. Every hour I spent learning a new tool's quirks was an hour I wasn't spending on their actual problem.

I also knew where the sharp edges were. When something broke, I usually recognised the error. With a new stack I'd have been searching forums for every odd behaviour, on a client's deadline.

And handover mattered. At some point someone else might maintain it. A common, well documented stack is much easier to hand to the next developer than something niche I happened to like.

What it cost me

It wasn't free. Some things were slower to build than they would have been with newer tools, especially parts of the UI. A couple of times I wrote code by hand that a newer library would have given me for free.

I also didn't learn much new on that project. That's a real cost if you enjoy the craft side.

How I decide now

For client work I use what I already know for the core, the database, the framework, hosting. If I want to try something new, it goes on a small side piece where a mistake is cheap, not in the middle of the build.

Do you pick your stack per client, or stick to one you know and accept the tradeoffs?