One principle in software development is YAGNI, You Ain’t Gonna Need It. This is a way of avoiding over-engineering systems by adding unnecessary complexity. The idea is that you don’t add anything until you actually need it. You deliver the simplest system that meets today’s requirements and iterate on it when you need to meet tomorrow’s. A simpler system should be easier to change than a more complicated system when the new requirements land.

That said, sometimes you do know you are going to need something in the future. Maybe you just need web based reports now but there’s a legal requirement to have them as PDFs you’ll need to address before you can launch. In that case it makes sense to design the system so that you won’t need to throw away the code for the web based reports and start again when you need to support the PDF versions.

This is different than trying to build a generic system that handles unknown requirements as you know what the future requirements are. Thinking of ways to build incrementally can help you break down the problem into smaller parts that build on each other. If you only focus on the immediate next requirement without looking up to see future ones then you could end up having to do a lot of rework.

What are you working on now that you have a high certainty you’ll build on top of later? Have you thought work you could do now to minimise the changes in future? Can you arrange things so if it turns out the future work isn’t needed the current code isn’t over engineered?