Hand me the system everyone's afraid to touch.
Not all of this job is greenfield. Sometimes you're handed a system that's already in production and already in trouble: real users on it, no tests, a team that's mostly checked out. The job is getting it stable again without tearing it down. I've done it more than once.
Stop the bleeding first
I took over a forex trading platform that had been left half-finished. TypeScript and React on the front, PHP and Laravel on the back, API contracts between them that no longer matched, no tests anywhere, live users hitting broken endpoints every day. Every instinct said redesign it from scratch.
I didn't. The first two weeks went to the endpoints actively corrupting data, and nothing else. The cosmetic stuff waited.
Then came the tests
Once the bleeding stopped, I wrote characterization tests for how the system actually behaved, wrong parts included. After that, every change had a baseline to check against.
Then the structural work. The frontend state was a mess of prop-drilling and misused context, so it got migrated to something coherent. The real-time WebSocket layer was rebuilt. The database got a real migration system, the first it had ever had.
Features were the last thing
Only once the foundation could hold weight did I start adding features. In the other order, every feature just loads more onto something already failing. By the time I left, the team had a codebase they could keep building on.
In practice
Took over a half-finished build with mismatched API contracts, no tests, and live users on broken endpoints. Fixed the data-corrupting paths first, wrote tests to lock down real behavior, then migrated the state layer and added proper database migrations. Features came last.
Most engineers avoid this kind of work. I look for it.