Hi there, I'm the author of the blog post. I realize I could have explained "over-engineering" more clearly. I don't mean it in a technical sense, but rather that I approached the project more like an engineer than a founder. The key takeaway is to learn when to take off your engineer hat and think like a founder instead.
I did read the whole article and based my comment on the coontents, not the title.
I think you're vastly underestimating the mental context we've gotten used to, and how hopelessly lost juniors are when confronted with such a large array of technologies that intertwine and only work in conjunction with each other.
The reason why these gigantic tech stacks exist in enterprise isn't because that's more stable, or better. It's because there are so many people working on the same software, and is hard to organize so many gears making all this tooling a necessity.
But the domain of a chat bot builder doesn't strike me as something you'll ever put multiple teams on, which was the reason for my mixed feelings.
Take a step back and look at your graph at the start of your article and imagine you've got ~1 month to introduce a junior developer to the whole tech stack. Do you feel confident that this is feasible? Because these kinds of projects almost always end up getting passed on, as they're usually not the core value products of the company
