Personally I love untangling old PHP/Ruby systems and striking that balance between paying down technical debt, squashing bugs, and getting new features to users.
I prefer the unique challenges of hundreds of thousands or millions of lines of code and a user base getting real work done with a system to the repetitive tasks of greenfield development ("oh joy, time to implement password reset again!").
PS If anyone is sitting on this type of challenge I've got my email in my profile, I am looking for some freelancing hours.
I feel much the same way. I love that feeling of deep familiarity you only get with a codebase that has some years behind it and you sharing multiple of those years with it. You get things like when a bug report comes in, and just from the description you can immediately realize some niche interaction that they've stumbled upon.
I worked on a greenfield project for a few years then went to working on some not so good legacy codebases and it turned out to be so much more satisfying. On the greenfield project we'd made a real effort to do everything the right way and avoid technical debt, but constant scope creep from the business eventually defeated us and it turned into a mess. Working on a messy old code base has been great because rather than taking the inevitable path to awful codebase, I've been improving the old code and making it pleasant to work with.
My experience is actually creating projects from scratch and outsource everything to 3rd parties (like using Firebase for everything). But lately I've seen that there are too many organizations (specially government and non-profits) that desperately need some improvement in their technology. And they need it more than a startup that is already in the bleeding edge.
I hope in the future people feel free to post job postings or freelance projects in this subreddit.
Michael Feathers working with legacy code book has been an absolute tome for working with old code. So many good ideas on how to tame code and find bugs and slowly improve the quality of it and its testability.
I've been thinking of using this as an office book club reading. We have some very important systems that have not been sustained, have no or very outdated documentation, and essentially no tests (or none of significant value, a single, fragile end-to-end test barely counts as a test when it can fail just for looking at it sideways on a Tuesday in May).
It's a very good book and more people should read it. Some great insights on how to get control of an existing system.
We're going to have so much fun migrating Wordpress websites while everybody is already on Solid React Angular that still forces you to implement all loading / error / done states per request.