I think people tend to talk past each other on this issue. The real problem with deciding upfront that something must be complex, is that it switches off that part of your brain which searches for simple, but hard-to-find, solutions. It encourages "greedy development" where you dive in before scoping out the best architecture, because who cares about the difference between complex and slightly more complex?
Actively searching for simple solutions to hard problems encourages high quality design and architecture. Moreover there is no one way to do simple things; simplicity requires a wider toolset than complexity. If your marketing explains how your tool helps people to make a complex thing, it's either incorrect or it's a bad solution.
So, let's say you take the simple solution. Then, the application keeps getting more and more complex due to the functionality requirements. Gradually, you've poorly and inconsistently implemented versions of the complex patterns in the first place, and the end result suffers for it.
I've dreamed of creating a multi-phase approach to software where simple and complex can co-exist and methodically transition along the way, but I've yet to be able to crack the problem.
You might have misread the thing I was proposing. If your application "keeps getting more and more complex due to the functionality requirements" then by definition there's no off-the-shelf library or service that can help. If your complexities are known in advance, you can choose a pattern which builds good, simple, composable code.
Honestly even if you're complexities aren't known in advance, it's still easier to build composable solutions out of off-the-shelf parts.
While I have nothing but empathy for our very-much shared pain, I have to insist that adding multiple layers of abstraction between a template and what the user sees in the browser + a maze of client/server sync flows + hyperactive ecosystem churn + webpack/babel + 750k npm packages because there's no stdlib = not a good start to finding a simpler A->B.
Actively searching for simple solutions to hard problems encourages high quality design and architecture. Moreover there is no one way to do simple things; simplicity requires a wider toolset than complexity. If your marketing explains how your tool helps people to make a complex thing, it's either incorrect or it's a bad solution.