The greenfield trap: when the foundation eats the budget

Greenfield sounds like freedom: an empty field, no legacy, everything new. In practice it first of all means that nothing is there. No cluster, no pipeline, no Terraform state, no database migration, no secrets. This article asks why exactly this part of a project is underestimated so reliably, why it nevertheless feels good while you build it, and in what order to approach it so that a product stands at the end and not just a foundation.

Contents

• Six weeks to the deadline, three of them in the engine room
• What is really missing on a greenfield
• Why the estimate for the foundation comes out too small
• Why foundation work feels like progress
• Time to first value
• The end-to-end path first: the walking skeleton
• What has to stand on day one and what can wait
• How thin can a foundation be?
• The three decisions that pull everything else along
• What happens when the foundation is added later
• Where Vela Atlas comes in
• FAQ
• Conclusion
• Sources

Six weeks to the deadline, three of them in the engine room

The scene repeats itself at almost every project start. A team gets six weeks until the first presentable state. The repository is empty, the domain is clarified, motivation is high. After three weeks a cluster is running, the pipeline is green, the Terraform module is cleanly cut. Business logic does not exist yet.

Nobody was slacking along the way. Every one of those three weeks was filled with real, necessary work. The problem does not come from bad work, it comes from the fact that this work never appeared in the plan at its actual size.

At the status meeting one sentence then shows up that everybody knows: the infrastructure is in place, now we can really get going. To the client that reads like half a project without a visible result. And half the budget is gone.

What is really missing on a greenfield

In a plan, “setup” is usually a single line. Unfolded, that same line looks like this:

• Cloud account, organization, projects or accounts per stage
• Identities and permissions: who may deploy, how the pipeline authenticates without permanent keys
• Network: VPC, subnets, outbound traffic, private reachability of the database
• Kubernetes cluster, node pools, autoscaling, resource limits
• Container registry including authentication from the pipeline and from the cluster
• DNS and certificates, including automatic renewal
• Ingress or gateway, plus the question of what is reachable from outside at all
• Secrets: where they live, how they get into the pod, how they are rotated
• Database, users, permissions, backups and a migration tool with a first baseline
• Deployment description, meaning Helm charts or the equivalent, configurable per stage
• CI/CD: build, test, build the image, sign it, roll it out, and that for every stage
• Logging, metrics, a health endpoint that says something you can rely on
• Local development environment that comes close enough to the target picture

That is more than a dozen topics, every single one of which needs a decision, an implementation and a test. None of them is hard. Taken together they are still weeks.

More important than the length of the list is one property of it: nothing on it distinguishes your product from the competition. The user does not pay for the ingress. He pays for what comes after it.

Why the estimate for the foundation comes out too small

Three mechanisms work together here, and all three pull in the same direction.

First, the foundation is estimated as one item although it is a bundle. The line “set up infrastructure” is judged by feel, as a memory of the last time. What gets estimated that way is the memory of the normal case and not the sum of the individual parts. Whoever estimates the list above line by line regularly ends up at a multiple.

On top of that, every decision drags follow-up decisions behind it. The choice of ingress determines how certificates are issued. That determines whether DNS has to be automated. That determines who needs write access to the zone. Chains like this are invisible while estimating, because you only ever see the first step.

And “done” means something different for the foundation than for a feature. A feature is done when it works. A piece of infrastructure is only done when it is reproducible, identical across all stages and still there after a rebuild. The distance between “runs in my cluster” and “runs exactly the same after terraform destroy and terraform apply” is often the larger part of the work.

There is a fourth point, harder to pin down. On a greenfield there is no excuse for not doing it properly. In an existing system, legacy holds you back. At the start nothing holds you back, and that is exactly the invitation to let the scope grow.

Why foundation work feels like progress

This work has a property that business logic does not have: it gives feedback immediately. A terraform apply goes through or it does not. A pod becomes Ready or it does not. A pipeline is green or red. Every one of those moments feels like a finished piece of work.

Business logic does not give that feedback. Whether the price calculation is correct in business terms, nobody knows for sure after two hours. That is less satisfying, and this is why the pull toward the engine room is real, especially for experienced developers.

Then there is the wish to do it better this time. You know the spots that hurt in the last project and want to solve them cleanly from the start this time. That is a good instinct. It only gets expensive when it meets a project that has not shipped a single line of business logic yet, because then you are optimizing for problems your product does not even have.

The honest check question in this phase is: am I solving a problem we have today, or one we had in the last project?

Time to first value

Most projects measure progress in closed tickets. That number rises reliably in the first weeks, even when the user gets nothing out of it. A more honest question is: how many days lie between the first commit and the moment a real user can do something that is useful to him?

This is not an official metric from any framework. The well-known DORA metrics measure something else, namely how fast an organization that is already running delivers changes. For a project start, the plain number of days until the first real value is still the most telling figure you can keep, and it has a pleasant side effect: it is not negotiable. A team can argue about how mature a pipeline is, about this number it cannot.

If you carry it along from day one, the discussion changes. “We still need GitOps” turns into “what does GitOps cost in days, and does it push out the first value”.

The end-to-end path first: the walking skeleton

The most effective countermeasure is old and comes from the early agile days. Alistair Cockburn coined the term walking skeleton and worked it out in “Crystal Clear” (2004).

What is meant is neither a prototype nor a finished module, but a path. Something tiny takes the complete route through every building block involved, and it does so before any of those blocks is expanded. What this path does in business terms is secondary. What matters is that it touches every block once, because that proves they fit together.

Applied to a cloud start today: there is a continuous route from a commit to a reachable URL in the target environment, before any of it is expanded. The endpoint may be trivial. What counts is that it is really delivered.

Such a path has passed when this sequence works without any manual step:

# 1. Change in the code, a single commit
git commit -am "add version endpoint" && git push

# 2. The pipeline runs through without manual intervention

# 3. The change is reachable in the target environment
curl -s https://api.dev.example.com/version
# {"version":"2026.08.05-a1b2c3d"}

When these three steps run, the riskiest assumption of the project has been checked: that the parts fit together at all. Everything after that is expansion, and expansion can be negotiated, postponed and prioritized. A missing end-to-end path cannot be negotiated, it blocks everything.

The pipeline that goes with it may be ridiculously small at the beginning. That is precisely the point:

name: deploy
on:
  push:
    branches: [main]

jobs:
  ship:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./mvnw -B package
      - run: docker build -t $REGISTRY/api:${{ github.sha }} .
      - run: docker push $REGISTRY/api:${{ github.sha }}
      - run: helm upgrade --install api ./chart --set image.tag=${{ github.sha }}

No test gate, no signature, no approval stage, no matrix across three stages. All of that will come, but it comes after the first end-to-end path and not before it.

What has to stand on day one and what can wait

The hardest question in this phase is not what you need. In the end you need almost everything. The question is which part of it has to stand before the first business logic.

The right-hand column is the more important one. It explains why a topic has to stand early, and the reason is almost always the same: if it is added later, substance that already exists has to be rebuilt. Everything that can be added later on top belongs outside week one.

How thin can a foundation be?

There is a usable yardstick from platform engineering. Matthew Skelton and Manuel Pais coined the term Thinnest Viable Platform in “Team Topologies”. The point sits in the word “thinnest”: a platform is not judged by everything it can do, but by how little it may contain while the teams on top of it still get ahead. Every capability that is in there has to be maintained by somebody afterwards, and that bill rarely turns up in the build estimate.

For a project start you can put it as a question: what is the thinnest foundation on which the business logic gets ahead today? Not the thinnest one you can defend, and not the most complete one you could build.

The yardstick is useful because it turns the discussion away from taste and toward a purpose. “Do we need a service mesh” is a matter of belief. “Does the business logic get ahead today without a service mesh” can be answered, and with a single service the answer is yes.

The three decisions that pull everything else along

Not all decisions weigh the same. Three of them determine so much follow-up work that they should be taken deliberately and early. The rest may develop over time.

The first is the separation of environments. Whether dev, staging and prod sit in separate accounts or projects or are only separated by namespaces decides permissions, networks, cost allocation and how dangerous a slip is. Changing that afterwards means creating every resource again.

The second is the path the pipeline takes into the cloud. Whether the pipeline identifies itself with short-lived tokens or with a permanent key is not a formality. One way gets by from day one without a secret in the repository, the other creates a rotation process that somebody has to operate. Not every provider offers both, so this belongs in the provider decision.

The third is the rollout procedure. Whether the pipeline rolls out directly or an agent in the cluster pulls a desired state from Git changes where the truth lives and what a rollback looks like. Both are defensible. Only switching mid-project gets expensive, because it touches every stage and every chart.

Everything else, from the choice of ingress to the migration tool, can be swapped later at reasonable cost. It pays to say this distinction out loud in the team once, so that the discussion time flows to where it changes something.

What happens when the foundation is added later

The counter-position to this article is widespread and sounds reasonable: build the business logic first, locally, without cloud, and the infrastructure comes when there is something to deploy. That saves time at the beginning and only postpones the work.

In practice this route costs you at three points. Assumptions from the local environment are firmly anchored in the code by then, for example file paths, time zones or a database that answers differently in the test than the real one does. Second, the first deploy falls into the phase where the deadline is already pressing, and infrastructure work under deadline pressure is the most expensive variant of it. Third, the feedback from a real environment is missing the whole time, so you find exactly the errors that arise there late.

How much work lies between a running deploy and real production readiness is a topic of its own. The way there is described in From deployed to production-ready.

Where Vela Atlas comes in

The list from the second chapter is remarkably similar from project to project. The business logic is new every time, the foundation almost never. That is exactly what Vela Atlas aims at: you configure your project, cloud, database, stages and services, and get the foundation rolled out instead of as a task.

Included is what stands above in the column “before the first business logic”: Spring Boot as the service scaffold, Terraform for the infrastructure, a Kubernetes cluster with Helm and ArgoCD, a CI/CD pipeline, a database with migrations, plus a handbook that explains the decisions that were taken. This is valuable above all when new greenfield projects start, where this base scaffold otherwise has to be built from zero and quickly costs weeks before the actual development begins.

Three providers are available as the cloud: Google Cloud, AWS and Scaleway. Scaleway is the European option, for when the data should not leave the continent. What that means in concrete terms is described in Scaleway is now on board.

The point is not that nobody could build this foundation themselves. Almost every experienced team can. The point is that these weeks produce nothing that sets the product apart from another one.

FAQ

Is this not an argument against clean architecture?
No. It is an argument against architecture work without feedback. A design that has never delivered anything is unverified, no matter how clean it looks. The end-to-end path delivers the feedback on which you can sensibly design further.

How do you estimate the foundation realistically?
Not as one item. Take the list of individual topics, estimate each line separately and add them up. The sum comes out clearly larger than the gut feeling, and exactly that difference is the amount that is regularly missing in projects.

Does this apply to brownfield as well?
Only in part. In an existing system the foundation is already there, but changes to it are more expensive. The trap in an existing system is a different one: the big modernization that runs alongside daily business and never finishes.

Is it worth it if we only have a single project?
The effort arises with the first project all the same. What is added with several projects is the consistency between them. With a single project what counts above all is when the first value appears.

Does a managed platform like Cloud Run or App Service not solve the problem anyway?
For a single stateless service often yes, and then that is the more honest route. As soon as several services, a database with migrations, separate stages and permissions come into play, a large part of the list is back again, just in a different place.

What about AI assistants, do they not simply write the foundation?
They write the individual building blocks fast and mostly usable. What they do not take off your hands is the decision about which blocks have to fit together, and the check whether the result is reproducible. The time saved is in the typing, not in the deciding.

Conclusion

Projects rarely fail because of bad architecture. They fail because the budget is used up before the first value was delivered. On a greenfield the danger is greatest, because nothing slows you down there and everything seems possible.

The next step is unspectacular: write down how many days lay between the first commit and the first real value in your last project. That one number changes the order in which you start next time.

Sources

• Alistair Cockburn: “Crystal Clear: A Human-Powered Methodology for Small Teams” (2004), on the walking skeleton
• Team Topologies (Matthew Skelton, Manuel Pais): What is a Thinnest Viable Platform (TVP)?
• DORA: metrics for delivery performance, as a contrast to the project-start question described here

All examples in this article are my own and deliberately cut down to the essentials.