The lesson here is to write code that's easy to throw away. The main problem here is commitment where it becomes too hard to change some fundamental aspects of your system. This time it leads to building an ad-hoc database, but another time it will be committing to a huge over engineered architecture because we might need it later. Both cases are caused by unnecessary coupling making it impossible to
untangle.
Take your best guess at what you will need later, but know you're guaranteed to be wrong because different products have different needs at different times and code for the future version of you that has to rewrite your persistence later.
Hacker News