There's a category of strategic decision we run into often: which technologies to standardize on. The temptation, especially with a strong engineering team, is to pick the latest, most innovative options — the new framework, the new database, the new programming language. The thinking is that you'll move faster with better tools. The result, played forward five years, is usually the opposite. The teams that ship fastest in year five are almost always the ones that picked boring tools in year one.
The reason is that all interesting technology has a rough first year. The documentation is incomplete. The library ecosystem is small. The Stack Overflow answers don't exist yet. The community is busy figuring out what the best practices are. Every problem you hit, you hit before anyone else does. You become an expert in this particular tool, which feels good — but the time you spend becoming an expert is time you're not spending on whatever your company is actually trying to do.
Boring tools have the opposite property. PostgreSQL has every problem written down somewhere. Django, Rails, Next.js — each has years of documented patterns. When you hit a problem, you Google it and find the answer in 90 seconds. The total time you spend on the technology itself is small, which leaves more time for the product. The teams that look slow because they're "still using" PostgreSQL are actually moving faster than the teams that are "on the cutting edge" — they're just less interesting to talk about at conferences.
Strategically: pick boring for the parts of the stack where you have no competitive advantage from being interesting. The database. The web framework. The deployment platform. The CI system. The monitoring tool. Pick interesting only where the interesting work is the work that differentiates you — your product, your domain-specific algorithms, the things customers come to you for. Most of your stack should be invisible. That's a feature.