I once worked for a startup that used Rails for building their web app. I would say around 50% of all development was in Rails. For things that demanded more pe

I once worked for a startup that used Rails for building their web app. I would say around 50% of all development was in Rails. For things that demanded more performance or correctness on complex tasks, there were some Java services and some Postgres sprocs. Our user-friendly and featureful website was a big part of our appeal. A lot of the non-Rails functionality was the unseen "secret sauce". I think this approach worked well. Most of what you need for a web app is commodity functionality. Correctness is not even particularly important in many cases. The Rails ecosystem has a lot of useful tools that make it easy. For example, there are multiple options for automatically adding a comprehensive admin panel. This let our non-technical admins manually accomplish CRUD tasks in the web app's domain. This allowed us to avoid overengineering. We could implement something that covered 80% of cases, and manually handle any edge cases or things that happened infrequently. An example is locking user accounts when a person left a customer's company; they could just email us and an admin would manually go in and check the "locked" box for the user. This allowed us to move very fast on new web app features, and focus on other aspects of the system. There were downsides, of course. One of the big pain points was upgrading Rails itself, and dealing with dependency hell at times with various libraries. You also have to know many things about how Rails works, which involves a lot of quasi-mysterious and implicitly-performed things. For example, I recall frequently coming across function calls, and then I would look for the function definition, only to find that it was a function that doesn't exist in the code and was generated at runtime by Rails.