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.
Adam Keys is typing 
I agree with every word. It’s worth mentioning that the GOOS guys (http://www.growing-object-oriented-software.com/) recommend building the skeleton of a working app and get the deployment sorted out upfront. I’d add monitoring into it, as well as any other needed integration with the rest of the system (logging, auth etc). And indeed, the sooner a green-field project is integrated with the entire system the better. It’s very important to identify the minimal set of requirements for the green-field project and stick to them, but as you mentioned, it’s hard.