Contagion and Children of Men - while they didn't look far into the future and dealt with existing problems, it's still horrifyingly accurate.
TheV2
But I do choose this approach for these problems to not have reusable code on purpose xD I'm not try-harding to rewrite everything for every feature separately, so most of it would be separated and modular, as long as it's required by the initial purpose of the software. However I avoid writing generic and reusable code that only gets rewarded with functional scalability in mind.
And unit testing is honestly not on my list for these kinds of projects. At best I'd write integration tests to challenge the route handlers. But simply using the software is sufficient to cover the predictably unpredictable usage in these cases.
Thanks for the recommendations. A missing understanding of what needs to be reusable could be a problem. E.g. in my example when I add a DAO-like interface just to implement it for the two entities I have, I invite my future self to add unnecessary features to make more use of that interface and other generic components.
It definitely is and I wouldn't take this approach mid-way for a project with multiple users and contributors. But it works for my little projects that desperately need me to be the user more than the developer. An example would be a REST API with a few endpoints where the database operations are handled directly in the route handlers uniquely for that specific task.
I assume that every decision I make I'll regret for what could have been and embrace for what has become. And that's only the small part of the future I get to decide.