The “green field” in software is a gift and a curse.
On the bright side, you have an opportunity to use the new-shiny. Past wrongs can be righted. You can move quickly, without worry about why some code exists, how it works, or whether you should care about it. Life is good.
The peril I’ve found is that green field projects are by their nature isolated. They don’t have a deployment or monitoring story. They don’t spring forth fully integrated with other critical systems. The project probably hasn’t proven itself as useful yet.
Letting a green-field live in isolation too long is the root of lots of problems. I’ve experienced scope creep, confused expectations, and declining morale that all could have been avoided had I brought a green-field project “into the fold” sooner. But the whole point of a green field is that you don’t integrate too soon, lest you spin your wheels on legacy things.
Green field projects are fun and an often welcome change of pace from working within an existing system. However, succeeding on a green field project is just as hard, or harder, than succeeding with a legacy system. It’s a different set of trade-offs that each developer has to get good at.