Greenfield is easy because nothing matters yet.
No legacy data. No backwards compatibility. No users depending on uptime. If the architecture is wrong you just rewrite it, rename a few services, and move on.
Maintaining and expanding a real system means every change has consequences. You’re migrating live data, preserving behavior people rely on, and evolving the architecture while the plane is already in the air.
0→1 lets you be bold because you can break things. 1→10M is harder because you can’t.
(I'm just kidding, your dismissal just needed a dismissal to make things balanced again)
But yes, as everything in life, YMMV and all jobs are a double edged sword. Some greenfield is shit because shitty decisions were made. Some enterprise is shit because some shitty decisions were made. In either case, whether it’s a new project or fixing an old one, take your time and not make shitty decisions.
(Spider-Man Point Meme)
(I don’t make products, I create legacies, in C++)
Maintaining and expanding is optimizing for throughput or reducing headroom so you can pack more compute.
Developing a greenfield solution requires innovation beyond a simple scaling issue. Often times, once a project like this is done, it lives in maintenance mode for the rest of its life and my skills would be better applied elsewhere.
Don’t get it twisted, I’ve scaled 0-1 to 10M and maintaining and expanding is a different skill set than innovating and invention.