Your library point is technically appealing, but economically it costs Microsoft nothing to include everything (since the code's already written), and adds some

Your library point is technically appealing, but economically it costs Microsoft nothing to include everything (since the code's already written), and adds some value for some people, helping to support a higher price. In fact, Microsoft tries to go even further the opposite way, by grouping Word with other software in Office. Instead of separating an application into libraries, they combine applications. But you can simulate the absence of features by hiding them. In terms of usability, Word defaults to hiding menu items, to remove the clutter of rarely used items. Many people don't like it, and turn it on, just in case they need something, but the fact that MS has chosen to make it the default maybe indicates that it's been favourable in their user trials (though they also choose clippy). The same thing could be done for vertical specialization. Finally, I agree with you about startup strategy. My reasoning is that you have limited time and resources for implementing and polishing features, so you'd better focus on what's really important. There's that marketing concept that if you really nail it for some specific niche, you'll be successful with them ("a small number of users really love you"). That's much better than making it almost acceptable for a huge number of people. I think that if you can later add other features that also have some value, you should. 37signals disagrees, saying you should keep the feature set tiny and unbloated (though they have added whole other separate products instead), But maybe there can be a natural life-cycle for vertical applications that grow and generalize into a horizontal application, as capabilities are (sensibly) added, as in "Text editors evolve until they can read mail. Those that can't will be replaced by those that can"