engineering

You don't need to plan ahead for future fields.  You just make the fields as you need them.  What is very important to get right is designing which tables you need and their relationships.

One thing you definately want to avoid is any concept of fields that are like [Sales 2026] where the field is hard coded for data entry or built in a summary field for a particular year.  That would indicate poor design which can be improved.  You want to never design an app that will need annual maintenance to roll over to a  new year. 

I would say the main clue is when you start making multiple fields to hold very similar data. For example, you make a file attachment field and then you say well maybe they want to upload three documents so I'll go file attachment one file attachment two and file attachment three. This is a very expedient to do on the parent  record, but inevitably someone is gonna come along and say well I have four documents to upload to this project record.

Then you realize it would've been better to have a child table of documents and that way you can categorize the documents and you don't really care how many they upload. 

The same thing might hold through for a project notes field. At first, you think I'll just give them a note field and  they can do updates. But then you realize you really wanted to track who made the note and when and in what sequence so you realize it would be better to have a child table for project notes.  Having a trial table, also gives you more granular control over which users can view an update the records.  

for example, going back to the earlier example of a trial table for documents, perhaps some document types are more confidential than others. So based on the document type, you can restrict access.