The most successful software I have ever built ran on technology that was embarrassing to admit at the time. PHP when everyone was doing Node. PostgreSQL when everyone was doing MongoDB. Server-rendered HTML when everyone was doing SPAs. Cron jobs when everyone was doing event-driven architecture.
I was embarrassed about these choices at meetups. I felt like I had to apologise for not using the cool stuff. The other developers talked about their microservices and their Kubernetes clusters and I smiled and nodded and went home to my monolith that actually worked.
Here is the thing though. My boring stuff shipped. It ran. It made money. It did not wake me up at 3am. It did not require a platform team to maintain. It was embarrassing and it was a competitive advantage.
When you choose boring technology, you choose technology that is well understood. The failure modes are documented. The solutions to common problems are Stack Overflowed. The community has seen everything and knows how to fix it. This matters more than features. The cool new thing might have better theoretical performance or a cleaner API or some architectural purity. But it also has undocumented edge cases, unresolved GitHub issues, and a community that is still figuring things out. Every hour you spend debugging novel problems with new technology is an hour you are not spending on the actual product. Boring technology gives you that hour back because the problems are already solved.
Try hiring a Rust developer. Try hiring someone who knows your particular flavour of event sourcing. Try finding a contractor who can jump into your Elixir codebase. Now try hiring a PHP developer. Try finding someone who knows PostgreSQL. Try handing a React codebase to literally anyone who has touched JavaScript in the last decade. The talent pool for boring technology is enormous. The talent pool for interesting technology is not. When you need to scale the team or replace someone who leaves, boring technology means you can actually find people. This compounds over time. Interesting technology accumulates knowledge in the heads of the few people who understand it. When they leave, the knowledge leaves. Boring technology spreads knowledge across many people who can be replaced.
New technology changes constantly. The framework you learned last year has breaking changes this year. The library you depend on got deprecated. The patterns you followed are now considered anti-patterns. This churn is exhausting. You spend time keeping up instead of building features. You refactor to accommodate breaking changes. You migrate because something you depend on is no longer maintained. Boring technology changes slowly. PostgreSQL has been stable for decades. PHP 8 runs PHP 5 code with minimal changes. React has evolved but the fundamentals from five years ago still work. Stability is productive. Churn is not.
If you feel embarrassed about your technology choices, that is often a sign you made good choices. The embarrassment comes from social pressure, not technical merit. The industry wants you to use the new thing because the new thing is interesting to talk about. Interesting to talk about and good to build with are different qualities. The developers who brag about their cutting-edge stack are often the ones with the most production incidents and the most maintenance burden. They traded reliability for status. That is a bad trade. The developers who sheepishly admit they are still using Rails or Laravel or WordPress are often the ones shipping features while everyone else is fighting their infrastructure. They traded status for productivity. That is a good trade.
I am not saying always choose boring. Sometimes the new technology solves a genuine problem that boring technology cannot. Sometimes the performance characteristics actually matter. Sometimes you need something that did not exist five years ago. But these situations are rarer than the industry pretends. Most applications do not need bleeding-edge performance. Most problems have been solved by boring technology. Most of the time, the interesting choice is a vanity choice dressed up as a technical requirement. Choose interesting when you have to. Choose boring when you can. The boring choice will embarrass you at conferences and serve you well in production.
Your competitors are busy rewriting their infrastructure for the third time because the cool framework pivoted. You are shipping features on your embarrassing stable stack. The embarrassment is a competitive advantage. Embrace it.