Keeping it simpleSo, KISS is for "Keep it simple, stupid" and it makes itself pretty clear. Just stay simple. Don't get fancy when you don't have to. This idea comes from an agile perspective, where a big design in the beginning is replaced by incremental design while the development takes place.
So instead of thinking ahead about future use cases, start with what you need now! Working in a startup, this is our daily business. We have neither time nor money to think ahead. And that saves us money because when you think about the future, most of the time you get it wrong. You design a website to be optimized so 10000 visitors can view it at the same time just to discover that you barely have 100 visitors but some features you never thought about are wanted by almost all your customers. Would you have this features if you didn't optimize? Well, no, but you would have a working software month before you actually finished developing and by now would have some of the features users want.
Of course this is about balance. If you start a new web app, not optimizing at all and having problems when 10 vistiors viewing your page brings you nowhere. The same is true for design. If you want to implement a REST API, you want to think about how to handle requests to a web server from the beginning. But you don't need to think about how to structure 100 different resources.
Thinking about requirementsThis also applies on requirements! In my opinion, many "features" which get written down in requirement documents are more disturbing than helping. If you don't get rid of these requirements, you end up with a far more complex application than you would need.
As an example, last week a co-worker started implementing a backend for on of our web applications. Till now we simply use the database to look thinks up and want to have a web backend where non-developers can have a look at the data. He approached me with my opinion on how to structure the search and filter features for one specific table. My advice was very simply: Don't implement it at all. My reasoning was very simply: In the whole livetime of the application no one of us ever searched or filtered the table in question, so why would we need it just because it's in your browser? My other argument was that we could add such features anytime if they are really needed.
So, when thinking about features, I tend to first get the basics right. What do users really need to work with the software I'm developing? This only includes the stuff which, if not there, makes the application unusable. This application can be shipped, because it is usable. If I can ship it, I can get feedback from internal or external customers (Internal customers may be employees that "test" the application, a product manager or someone like this).