I worked with a four person startup tech team that shipped a production rails system in six months based on a python/flask/mongo prototype that I demoed in a week a decade ago that is still being used and sold today, though I'm not sure of its technical evolution.<p>I've built a few Sinatra/Flask systems since, so I'm definitely a fan of the virtue of simplicity, no matter the language.<p>The design mistake here is not applying lessons learned reading Danny Greenfeld's book (which I don't believe shipped before 2012) on Django and realizing the chapter on "vanilla Django" applies just as much to any system, like "vanilla Rails", because they are the same "stranger in a strange land" problems where the system as we know it becomes undocumented and unbounded by architectural style - a kind of McMansion Hell for system design.<p>The use of DSLs is complex territory. When in the hands of a master, amazing work can happen, but when too many DSLs are combined together, you wind up with exactly the opposite of what Greenfeld described in the chapter on vanilla Django, you wind up with byzantine Rails, because the boundaries that Alan Kay described decades earlier are not architectural. As with much software, there is no physics, real or implied, that applies to the phenomenological understanding of the system, the individual and social human scaling of brains that turns out to be a larger problem than computer hardware and software scaling.<p>There is a semantic asymptote, if you will, where the problem leaves the empirical world and becomes phenomenological - very difficult to share socially unless you are Kay, Knuth, or one of their contemporaries.