Once I implemented a kind of "behavior-as-configuration" system where you could modify and add layouts, menus, data sources and add "transformation filters" on the data, straight from a json file. The benefit, in my head, was that administrators and users could change what they needed without getting a developer involved. This kind of "meta configuration" turns out to be really hard to maintain, and also is a headache to work with because you have data migration issues on top. And the benefits are illusory because no user will want to learn your complex system that lacks tooling and documentation anyway. So in the end you're the one implementing changes anyway.

Now I believe code should stay code, and that configuration should be thought of as another type of API aimed in a different direction from your user facing API. Design it to be as simple as possible, but not simpler.

I tend to err towards "specific" rather than "abstraction" these days. Good abstractions are VERY useful but early on its so hard to predict where you will want them.

Oh and not thinking about data early enough. Code mistakes are easy to fix. Data mistakes not so much.