Alright after working on several projects on my own for a long time and now with a small group for close to 2 years I've seen how some projects succeed and how

Alright after working on several projects on my own for a long time and now with a small group for close to 2 years I've seen how some projects succeed and how others fail to ship. So here are few thoughts to hopefully help. You stated it yourself, plan first. Define exactly what you are shipping. If you don't do this - it's going to feel like the development is never going to end because it never really will end unless you have a well defined stopping point or a set of features that you just won't ship without. A lot can be said on how you plan - this can vary widely based on the type of project you are working on. You mentioned building a simple web application so here's my advice for that - be very clear with the objective of your project then use a method like moscow to prioritize feature ideas. Our minds run wild during brainstorming but lets reel it in to factor in our time constraint. So throw out everything non-essential - and when I mean non-essential it should make you feel uncomfortable with the amount of stuff you throw out. TODOs are a good step - my only practical recommendation here is to go up a level of granularity. Define user stories/scenarios and/or features (I go without defining features and just leave it at user stories since this is enough for me) and tie your TODOs to these stories. Don't underestimate this work. This will help you make that context switch between development and the bigger picture of your project and who your users are. I use GitHub and use their board to to tie in my issues with pull requests. If you use github do that - keep your TODOs close to your code maybe even track it in source control. Up to you. > between just shipping a product and following the best engineering practices and actually defining what I really want to do.... Here are thoughts for your concerns. boiled down to a few words. > shipping product Plan. > following the best engineering practices Forget the deadline. > actually defining what I really want to do Stop and ponder.