Heard of Y.A.G.N.I. (You aren't gonna need it)?
Do the simplest thing that could possibly work.
This concept can be a dangerous one to introduce to junior developers. This does not mean you just code the first thing that you can get working. You always need to do your due diligence w/r to data model / api / architecture. Make sure you understand where you are going... But once armed with a design, the general idea is to implement the things that are going to be used today.
But why wait? The risk is exceptionally high when you combine YAGNI and an immature product. When you are in this embryonic state you know very little about the technology you are using, your users, domain, or even the problem you are solving.
So you develop some futuristic feature. ......Fast-forward "X" amount of time
- You discover you really didn't need it (time and money was wasted)
- The feature doesn't work or is buggy (and you don't remember anything about how or why you added it so it takes forever to fix it)
- Or now you have a better understanding of the domain/technology and the feature was poorly implemented or designed and you need to redo it (technical debt).
- Oh yea... there is the chance that the feature worked... (congrats you just won the lottery).
What about those sections of code that have developed cobwebs?
//uncomment this when you want to update users . Code branches that have not been touched in months? Delete them! Untested code, in my mind, is broken code. I don't trust any code that is not actively being used, and neither should you. Every feature you add, is a feature that someone else will have to maintain, understand, or use.
It's hard to talk about Y.A.G.N.I. without mentioning Keep It Simple, Stupid. Which basically says only add complexity when it's needed. Easiest example is don't create the "Shape" abstraction if your system only talks ,and for the foreseeable future, only draws "Lines".