The planning instincts that work cleanly on a new project quietly break on an existing codebase. An experienced lead who can deliver a greenfield application on time and on budget can land inside a brownfield engagement and miss the estimate by fifty percent — not because they got lazy, but because the assumptions they were relying on do not carry over.
This piece walks through the assumptions that need to invert when the project changes type, and how to estimate and plan honestly for each case.
The assumption that fails first: discovery cost
On a greenfield project, discovery is mostly about the business. What does the user need? What does the data shape look like? What are the regulatory constraints? Once those are answered, the engineering team has clear canvas.
On a brownfield project, there is a second layer of discovery that does not exist in greenfield work: mapping what the existing system actually does. Not what the documentation says it does — what it does. Every non-trivial legacy codebase has dozens of behaviors that are not written down anywhere, because they were added to fix specific bugs or handle specific customers, and the person who added them did not update the spec.
This hidden discovery cost is the single largest reason brownfield estimates come in low. An engineer looks at a module, thinks “this is a two-week change,” and does not account for the week they will spend figuring out why the existing code takes a peculiar path through a nested conditional that turns out to exist for a compliance reason nobody mentioned.
Rule of thumb: in brownfield work, the first third of any estimate should be discovery — reading code, running traces, writing characterization tests to capture current behavior before touching anything. If that phase is not in the plan, the plan is wrong.
Test scaffolding: optional in greenfield, non-negotiable in brownfield
In a greenfield project, tests grow alongside the code. You write the new feature, you write its test, they are born together. The code is structured to be testable from day one.
Legacy codebases almost never have this structure. The code predates whatever test culture exists today, and large parts of it were never test-covered. Before you can safely change anything, you need to build test scaffolding around the area you are touching — enough to detect regressions when you make changes.
This work is invisible to the business. It produces no new features, no user-visible output, no release notes. It is also the single highest-leverage investment in a brownfield project. A team that skips it ships faster for two weeks and then spends two months chasing silent regressions.
The practical consequence for planning: in brownfield work, allocate roughly twenty to thirty percent of the effort to characterization testing of code you do not plan to modify directly. That sounds excessive until the first time a change in module A breaks something in module B because module B was reading module A’s internal state through a side channel.
Coordination overhead
Greenfield projects are typically owned by one team, end to end. There are external stakeholders, but there is usually no one else writing code in the repository.
Brownfield projects are almost always shared. There is a team that owns the existing system and has been maintaining it for years. They have opinions about the codebase — usually correct ones — and they have commitments to existing users that the new work can disrupt. Even when the new work is politically blessed from the top, the day-to-day coordination is real.
The specific coordination costs that show up: code review with a team that has a higher bar for changes in their module, merge conflicts with ongoing maintenance work, and scheduling around release trains that the new team did not set. None of these are visible in a backlog. All of them consume calendar.
If the brownfield project crosses more than two existing teams, budget a full-time technical program manager. That is not bureaucratic bloat — it is the person whose only job is keeping the coordination overhead from silently eating the engineering capacity.
The velocity curve looks different
Greenfield velocity looks roughly linear. Early weeks are slow because there is no infrastructure, then it picks up and stabilizes. Features ship at a predictable cadence.
Brownfield velocity follows a different shape. It starts slow — often slower than the team expects — because every change requires understanding the existing context. It stays slow for longer than feels comfortable. Then, somewhere around the midpoint, it accelerates sharply as the team builds up mental models of the codebase, establishes the testing scaffolding, and identifies the safe refactoring moves. By the final third of the project, velocity is often higher than the equivalent greenfield team’s.
The trap is that executives watching the first two months compare velocity to a greenfield reference class and conclude the team is underperforming. They are not. They are on the normal brownfield curve. Leaving that curve unexplained is how good brownfield projects get canceled at the worst possible moment.
Silent regressions as a category of risk
In greenfield work, bugs are visible. A feature either works or it does not. QA catches the obvious cases, beta users catch the rest.
In brownfield work, the scariest bugs are the ones where something that used to work stops working quietly. A report that used to include a particular customer segment now excludes it. A batch job that used to run in forty minutes now takes three hours. Nobody notices for a week. By the time someone does, the change that caused it is buried under two more releases.
The mitigation is deliberate. Before changes ship, the team identifies the specific business-level behaviors that must not change — report outputs, queue throughputs, financial totals, customer-visible states — and sets up monitoring that alerts when any of them move outside expected bounds. This is observability as regression detection, and it has to be in place before the first change lands, not after.
Choosing greenfield or brownfield (when the choice is actually yours)
Sometimes a leader has a real choice: build a new capability from scratch, or extend an existing system to provide it. The instinct is usually to pick whichever path seems faster at first glance. That instinct is unreliable.
Greenfield is the right choice when the new capability is genuinely novel — a distinct product, a separate user base, a different data model. Forcing novelty into an existing codebase produces an unhappy hybrid that satisfies neither the old users nor the new ones.
Brownfield is the right choice when the new capability is an extension of what the existing system already does — another report type, another workflow variant, another user segment. Duplicating the surrounding infrastructure in a new codebase is how companies end up with three systems that all do half of what any single system should have done.
And sometimes the choice is not actually available. Compliance constraints, shared data, regulatory audit trails, or existing contracts can force a brownfield approach even when a clean greenfield would have been simpler. Recognizing when the choice has been made for you saves months of unproductive architectural debate.
Planning the right way for the project you actually have
The single most useful question at the start of any engagement is: which kind of project is this, honestly? Not which kind would we prefer it to be. Which kind is it?
If it is greenfield, plan like greenfield. Linear velocity, test-and-feature parity, fast initial progress, clean ownership boundaries.
If it is brownfield, plan like brownfield. Front-loaded discovery, explicit characterization testing, slower-before-faster velocity curve, coordination overhead as a line item, regression monitoring before any change ships. Communicate that shape to the executives funding the work before the first sprint starts, not in month three when the velocity gap becomes visible.
Most software projects that miss badly miss because they were planned as the other type. Naming the shape correctly at the start is often the single most valuable planning decision the team makes.
