This actually sounds like a promising idea, though only if you've got insane dev chops on the founding team. In the Ruby world, Sinatra would be the obvious place to start. On the other hand, you might just end up reinventing Rails.

I love Sinatra, but there's a long-running joke that if you look at the source for any Sinatra application with even a little complexity, you'll find a half-baked re-implementation of Rails inside. I've built apps like that and it's definitely not an exaggeration.

Ah, so following Greenspun's tenth rule [1], perhaps we have this:

  Any sufficiently complicated web application contains 
  an ad hoc, informally specified, bug-ridden, slow 
  implementation of half of Ruby on Rails.

[1] http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

That was my road to Ruby: Developing in PHP "mvc" frameworks. Even had a PHP active record implementation. Create function was used heavily ...

http://php.net/manual/en/function.create-function.php

That's probably almost the exact quote I saw :)

Yep, especially as there are sinatra stacks that already do that for you in a sane fashion, e.g. Padrino.

Also: yes, building from minimal makes you appreciate the work that big frameworks have already done.

Tried it. You spend way too much time solving problems that are already easily solved in the existing larger ecosystems.

Yes indeed, and also leaves everyone in the muck when the lead dev leaves. Your left with a load of code you had wish you had documented as well as the previous frameworks. The value of existing frameworks is the documentation and stack overflow answers.