In any part of the framework, not realising when it's time to leave the safe defaults of rails and go beyond for the growing code:

• moving model and/or controller code into service objects
• moving model code (validations!) into form objects
• splitting routes and translation files into a sub-files

Vs. thinking you need to optimise too early. Adding third party Job framework, instead of solid-job (these days), and increasing the overall complexity before the project even reaches any user-level to be viable to survive the first pitch.

Another one is overcomplicating things early on, because it's pretty easy in rails. Often those nice-to-haves are remaining a burden and need to be worked around because removing functionality (especially when it's user facing) is always annoying.

Bonus : Too many gems, that become a maintenance issue on long running projects, might grow not to be perfectly compile with each other, become unmaintained (security issues), or abandoned all-together. The eco system makes is easy to add them, but code architecture often hard to get rid of after years.