Just build what is necessary, always build for change
There is a tension when building software between spending time designing, planning, and up front thinking vs getting something shipped and getting feedback from real users.
If you spend too much time architecting and planning you might over-engineer a system and build things you don’t need. If you don’t think about what the product could end up being you might under-engineer a system and end up having to rewrite it completely.
You can ask yourself if what you’re working on now is successful what is that likely to mean? What are the most likely changes? Are there cheap things you could put in place now to make the most likely changes easier to make?
You shouldn’t build anything you don’t need right now. What you do build should be as easy to evolve as you can make it. This is hard!
(Title and thoughts inspired by a comment on a Kent Beck post)