Whenever you start a project (and I'm thinking about building websites and web applications), you are balancing two somewhat opposed goals: 1) get something working right away and 2) satisfy all your hopes and dreams. The first, I think, is a good instinct.  The second is the real challenge -- it's your wildest hopes and dreams for a project which can ultimately stop you from just getting something working, now, that accomplishes the smallest essential essence. Paul Graham and Eric Ries describe this as the Minimum Viable Product -- I agree with that idea completely -- but sometimes in practice it feels like even "MVP" ends up being bigger & more complicated than it should be.  I've worked on projects where the idea of "getting to MVP" looms large over the team -- I feel like when that starts to happen you're actually building more into your MVP than you should be.  The beautiful moment in building a product is the first time when it actually serves some basic need, and does that in a way that's fun to use.  And that moment can't come early enough. So, if you find yourself debating problems you don't yet have, or arguing the nuances of the perfect, most elegant data model, maybe the thing to do is stop completely and ask  yourself if the most basic essence of what you're making has been built, and if it has, if it's fun to use.  If it's not built yet, you should stop and build just the absolute simplest thing that works.  Not for public consumption, necessarily, but for yourselves and your team. If it is built, then you should ask: is it fun to use?  If it's not fun to use when it's at its most simple, it's only going to get harder to make it fun to use once it's more complex. Simple, and fun to use. I'm not saying I've successfully approached every project this way, but I try to, and will keep trying to.

Whenever you start a project (and I'm thinking about building websites and web applications), you are balancing two somewhat opposed goals: 1) get something working right away and 2) satisfy all your hopes and dreams. The first, I think, is a good instinct.  The second is the real challenge -- it's your wildest hopes and dreams for a project which can ultimately stop you from just getting something working, now, that accomplishes the smallest essential essence. Paul Graham and Eric Ries describe this as the Minimum Viable Product -- I agree with that idea completely -- but sometimes in practice it feels like even "MVP" ends up being bigger & more complicated than it should be.  I've worked on projects where the idea of "getting to MVP" looms large over the team -- I feel like when that starts to happen you're actually building more into your MVP than you should be.  The beautiful moment in building a product is the first time when it actually serves some basic need, and does that in a way that's fun to use.  And that moment can't come early enough. So, if you find yourself debating problems you don't yet have, or arguing the nuances of the perfect, most elegant data model, maybe the thing to do is stop completely and ask  yourself if the most basic essence of what you're making has been built, and if it has, if it's fun to use.  If it's not built yet, you should stop and build just the absolute simplest thing that works.  Not for public consumption, necessarily, but for yourselves and your team. If it is built, then you should ask: is it fun to use?  If it's not fun to use when it's at its most simple, it's only going to get harder to make it fun to use once it's more complex. Simple, and fun to use. I'm not saying I've successfully approached every project this way, but I try to, and will keep trying to.