The most general answer to the "off the shelf vs. custom" question is pretty much what @robin-vessey says. Succinctly, is your product the audience you build, or is your product the technology you build? If the first, off the shelf works great (see countless valuable online publications for evidence); if the second, it probably won't long-term.
...if we were to develop a minimum viable product / proof of concept /
prototype using Drupal, other developers could own copyright to their
modules.
I think copyright is a red herring for this particular question. It boils down to this regardless of your technology: If someone besides you wrote something that you plan to sell, you must secure a right to sell it. For many libraries (I believe this is true in the Drupal community, too) that right is given freely, preemptively through license.
If we take the time to develop the proto with Drupal, add the rewrite
time and measure it against just writing a custom application, could
we come out better just writing a custom app using something like
CodeIgnitor, Zend or Rails?
Let's assume that no other variables are in play (which is a false assumption: lots of other variables are in play, such as the skillset of your team, the location in the stack of your IP, the technology you eventually migrate to, etc.): You will probably spend more time building it in Drupal and then rebuilding it elsewhere than you would if you just started elsewhere.
That being said, there is a strong case to be made for prototyping using the fastest possible prototyping solution, because doing so can give you rapid insight into things you can only learn from your market.
On that note, if you haven't already, consider prototyping in something even more lightweight than Drupal. Like static HTML. Or Balsamiq. Or paper. If you show the right people what you're thinking, you'll get more insight into this question and many others.
Also, by building a custom app we know the inner-workings and don't
have to reverse-engineer anything nor sift through mountains of
sometimes fragmented documentation.
Well, maybe. A custom application built on one of the frameworks you mention may require engineers to sift through mountains of something, that's for sure. I think when you're building innovative products on the web, you're going to be sifting. That's why it's important to choose tools that your engineers don't mind fighting sometimes.
A couple other quick notes that may inform this discussion:
- It can be tough to find engineers who are productive and happy jumping from a "bought" to a "built" solution. Bridging the difference between a CMS and a framework can create some real frustrating inefficiencies that many developers choose not to fight.
- While I can't recommend this from firsthand experience, since CodeIgniter is the framework underneath ExpressionEngine, and ExpressionEngine is arguably equivalent to Drupal in capabilities, you might be able to transition from bought to built that way.
- Anything you can do to avoid throwing something away wholesale may help you maximize your development dollar. If the product doesn't belong in Drupal at the end, using Drupal at the beginning means throwing away Drupal halfway through. But it sounds like your product will have some HTML, so using static HTML at the beginning might just mean coding your static HTML in your framework's views halfway through. One tool that can make this downright fun is a static site generator like Middlemanapp, especially if you're headed toward Rails.
