There is a temptation in every engineering project to use the new thing. The new framework. The new language. The new database. New things are exciting. They are also undertested, underdocumented, and underpopulated with experienced engineers.
We have made this mistake. Early in the company we shipped a client project on a trendy new framework. Two years later the framework had lost momentum, the maintainers had moved on, and the project was the only one we had running on it. Every upgrade was a gamble. Every new hire needed training. The "innovation" had become a tax.
Now we ship on boring. Postgres. React. TypeScript. Node or Python. AWS or Vercel. These are old, or old-ish, and widely known. Every engineer we hire already knows them. Every problem we hit has been solved on Stack Overflow five years ago. Every library has a plausible upgrade path to something still being maintained in 2030.
The opportunity cost of boring is that we are not on the bleeding edge. We do not get to write blog posts about how we are using the hot new vector database or the new serverless framework. That is fine. Our job is not to be interesting. Our job is to ship software that works, keeps working, and does not become a liability for the client a year after delivery.
The clients who have been burned by a previous agency always ask us about the stack choice. They want to know we are not going to leave them holding a codebase that only five people in the world can work on. Boring code answers that question. Anyone can hire for it. Anyone can maintain it. It will still be a working system in 2030, probably still in 2035.
There is a place for the bleeding edge. It is research projects, not line-of-business systems. If you are shipping a custom app that your operations team will depend on for the next five years, ship it on the stack your operations team can still find engineers for in 2030. That is the job. It is not exciting, and that is exactly the point.