Let me begin with an imaginary story. Imagine...
You're developing this fancy blogging platform. You know your users and you know that while writing, they would like to know how long it'll take the reader to read their post. Since you know your users so well you also know their typical reading speed, so the reading time is a straight-forward calculation. You can continuously recalculate the value in the frontend while the user is typing. You're excited. You don't always get such well-defined tasks. It's almost too good to be true. And naturally, you begin to wonder: what if there's more to this? Will your solution be future-proof? What if at some point you want to show the reading time not only to the writer but also to the readers? What if some other service wants to use this data to do some analysis? You're sure you need to move this calculation to the backend and provide it through the API, so it can be used by other services but calculating it for every request would slow it down. You know that can be solved by storing the calculated value in the database alongside the article but that would add redundancy which brings with it the risk of data corruption. Anyway, you know that rules are there to be broken and you know that there are actually good reasons to introduce redundancy to a database, one of them being performance gains.
So you know what you need to do: You calculate this value in the backend every time you create or update an article, save it to a database, and on the frontend, you get the updated value every time the article is saved. Now, you can show it to the writer. That solves all your problems, you just need to hide the value if the user has unsaved changes because you won't be able to update it in real-time.
Congratulations, you solved an imaginary problem. Sure, you introduced the risk of data corruption and compromised on the user experience but you solved a lot of exciting problems along the way.
The only thing is, imaginary problems aren't real. The time might come that, based on actual user research, you decide to add the reading time to a list of suggested articles. At this point, putting the value into the database might be a valid solution. But guess what, not everybody is the "typical reader" and maybe you decide to display the reading time based on the reader's actual reading speed. Or you don't. That's the point.
The opportunity of solving complex problems is tempting but what really adds value to any product is making complex problems simple. Instead of asking yourself "What if?", ask yourself "What is the essence of this problem?", "What is it that adds value to the product?". Simplify, not complicate, problems.
Having said that, building robust software and adhering to basic design principles might sound like future-proofing your solution for imaginary problems but it is really not. It is future-proofing your solution for any future problem. Building APIs in a way that allows further development without breaking changes is generally a good idea.
Finally, if you're doing a project for fun or to learn, solving imaginary problems is great. Keep going. Also, remember: you don't need to solve any problem at all. There are a lot more reasons to start projects or write code.