> While I always felt that I want to achieve more than these regular old CRUD apps, no “10xer” would implement them faster/better
A "regular old CRUD app" doesn't exist. Poor development teams end up translating all requirements into "regular old CRUD apps" because that's easier. Humans are excellent at replacing hard problems with easy ones, regardless of whether solving the easy one is anywhere near as useful.
And yes, they absolutely would implement them faster. Most "regular old CRUD apps" are rife with SELECT N+1 and other simple and crippling performance issues.
> “these systems are building the rails in front of the train”, and it is not even an engineering problem most of the time.
You're assuming we're stuck with trains and rails. In the physical world, we are: if I invent a different kind of train that doesn't need rails, or a completely different way to transport freight, then I've solved about 1% of the problem -- we still need to build out all the infrastructure around it, change all our systems to use it, etc.
If I invent a different kind of process for handling data flow in an application, I've solved somewhere between 40% and 100% of the problem, depending on how 'private' it is, etc. "Building" the thing takes the compiler a few seconds. We might still need to adjust downstream dependencies, but if they're also written well, that should be extremely easy.
> it is a super-human, not-really-compressible complexity
While this definitely exists, my claim is that the intrinsic, Kolmogorov complexity of the problems most existing software solves is somewhere between 10% and 1% of the actual complexity of that software.
Sometimes upstream processes will need to change (usually becoming much simpler). This is usually the sticking point. if the upstream process is the U.S. Code of Federal Regulations, then this isn't likely (without lots of lobbying money to simplify it, which the FAANGs of the world should actually consider a tool in their toolbox, but most of us can't), and we can call the "intrinsic complexity" high.
But more often than not, that complexity is actually coming from the whims of some previous moron vice president who now works somewhere else, and they're conflicting with the whims of the current moron vice president. My whole point here is that the staff-level developers need the authority to tell those people to shove off and implement it in a way that actually makes sense. Yes, I'm aware that will never happen because of the deep toxic dysfunction endemic in modern corporations -- this is my point.