Always strive for simplicty. Avoid redundancy.
Start writing non generic code, top down, doing just what is needed.
Later, refactor anything that looks like a generic construct and break it out to a separate component. And test it.
Iterate.
Keep interfaces small. Imagine using your api/class by writing some pseudo code to help realize what it should do. Don't proactivly add to your API. Once used you can usually never remove it.
Even if a peace of code is only used once, and you are sure it will not be needed again; break it out into it's own function if it's generic enough so you can name it. This has the added benefit of discouraging any non-generic change to that peace of code.
Avoid directly mirroring your data model (like reading/writing json directly from serializable classes). Data storage and runtime use are different use cases and usually need different layouts.
Don't try to model soft/unclear/changing requirements and designs to strictly defined types in your code. The inevitable changes will lead to a lot of extra work, and 3rd party designs are unlikely to go together with simple code.
Real World Application = A simple, clear design + a set of exceptions & rules that bend the design into the required thing.
Try to make the last part as small as possible, and understandable.
A design (and language) that helps you define these exceptions in a readable way will help. One way is to use callbacks or signals to allow injection of code into relevant places. Another way it to use an embedded scripting language for the business logic.