I agree that it's unrealistic to deliver huge features quickly with no bugs. I'll propose a different alternative, though: I would rather start with simpler features that work for the main use case and fail gracefully for negative/edge cases, so users have a good experience most of the time and a clear exit path when they wander into an area that the product doesn't solve yet.
For example: We think our primary customers need to come in, take care of a task (e.g., enter an expense), and save the result. The founders want to support cash expenses, credit cards, and prepayment for travel expenses as "the first feature." They also want reports on expenses that have been entered, chat between the submitter and accounting, and an approval process.
Before I build all of that, we're going to:
1. Break features down into their simplest functional use cases (a user can complete an action and see value from it). This includes defining what v1, v2, v3, etc., of those paths could look like, so we can see how the feature set gets richer over time and also be able to start with the simplest version that's meaningful.
2. Prioritize those use cases and understand how they can layer together to build an ever-richer product. Do we need expense entry to get really fancy before we introduce reports, or should we get simple data entry and reporting before we add interactivity to the app?
3. Build and deliver each use case individually, so that each one works well for the main case and gives the user a path out when it fails. I try to keep delivery simple and features small so we know one thing works before we add the next.
4. Learn from actual users whether our guesses about what was important to them were correct. If not, keeping things small, modular, and functional lets us change course/reodrder priorities without too much pain.
And while I want to make sure that we can handle the user load, I'll never worry about scaling more than 5x our expected volume (2-3x in the first year of the product's existence) until volume becomes an issue. In the meantime, I'll accept additional hosting costs if I need to boost hardware to support growth. By always building solid, simple code, I give myself room to learn and adapt, and I don't piss off my users if I can't come back to a feature for a while because, even if it doesn't do everything, it works. If I start with buggy code that tries to do too much, I piss off everyone.
