TL;DR
A greenfield project builds on nothing. No existing code, no existing data, no users with habits. You choose every constraint.
A brownfield project builds on something that already runs. The constraints were chosen before you arrived, by people who may no longer be around, and the system has users, data and opinions.
Most MVPs are greenfield, which is why founders assume theirs is. The ones that are not, the add-on to an existing business, the inherited codebase, the product that has to talk to a twenty year old system, cost 30 to 60 percent more than the same scope built fresh, and the extra is almost entirely in the parts nobody puts on the feature list.
Greenfield vs brownfield software development at a glance
| Greenfield | Brownfield | |
|---|---|---|
| What exists when you start | Nothing | A running system, its data, its users |
| Who chose the constraints | You | Someone before you |
| Tech stack | Open choice | Largely inherited |
| Data | None yet | Live, must be preserved |
| Users | None yet | Existing, with habits |
| Discovery needed | Product discovery only | Product plus technical archaeology |
| Testing | Test what you built | Test what you built and what you did not break |
| Time to first commit | Days | Weeks |
| Typical cost vs same scope | Baseline | +30 to 60 percent |
| Biggest risk | Building the wrong thing | Breaking the right thing |
| Where MVPs sit | Most of them | Rebuilds, add-ons, integrations |
The row people underestimate is the testing one. In a greenfield build you test what you made. In a brownfield build you also have to prove you did not break anything that was already working, and nobody has a list of what was already working.
What is greenfield vs brownfield?
The terms come from construction. A greenfield site is empty land; you can put the building anywhere. A brownfield site has something on it already, often something that has to be dealt with before you can build.
Software borrowed the words because the distinction maps exactly. People search it both ways, greenfield vs brownfield and brownfield vs greenfield, and mean the same thing: which of the two situations am I in, and what does that change.
What matters is not the metaphor but what each one does to your project.
Greenfield, defined
A greenfield project starts with no existing system to accommodate. No legacy code, no schema, no integrations, no users who have learned how the old thing works.
Every decision is yours: language, framework, hosting, data model, what the product even is. That freedom is the whole point and, as we get to below, also the trap.
Brownfield, defined
A brownfield project starts inside or alongside something that already runs. The something might be a product you are replacing, a business system your product has to read from, or a codebase you inherited when you bought a company or hired a team that then left.
The decisions that matter most were made before you arrived. Your job is partly to build and partly to understand what you are building on.
The word missing from both definitions
Quality.
Greenfield is not automatically clean and brownfield is not automatically messy. A greenfield build by a rushed team produces a brownfield problem within a year. A brownfield build on a well-kept system can be a joy.
The terms describe your starting conditions, not the outcome. Treat them as a description of risk, not of merit.
Greenfield vs brownfield projects: what actually changes
Four things, and they compound.
Constraints you chose versus constraints you inherited
In greenfield, when something is awkward, you change it. In brownfield, when something is awkward, you first have to find out why it is that way, whether anything depends on it, and who will be upset if it changes.
That question, “does anything depend on this”, is the single most expensive sentence in brownfield development. It rarely has a documented answer.
The data problem
A greenfield product has no data yet. Its schema can be whatever the product needs.
A brownfield product has data that already exists, in a shape somebody chose years ago for reasons that made sense then. Customers with three different identifiers. Dates stored as text. A status field with fourteen values, six of which are not used but might be.
You cannot design around it. You have to design through it, and every workaround you add is a constraint the next team inherits.
The integration problem
Greenfield systems talk to whatever you decide they talk to. Brownfield systems have to talk to what is already there, on its terms.
An old system’s API returns the fields it returns. If the field you need is not one of them, you are either reading a database you were not supposed to touch or waiting on a vendor. Both cost weeks that never appear on a feature list.
Who else has an opinion
A greenfield product has one stakeholder group: the people building it.
A brownfield product has everyone who uses the existing system, everyone who supports it, and everyone whose reports depend on it. Each of them has a reason the thing you want to change should stay exactly as it is.
Why most MVPs are greenfield, and when yours is not
An MVP is, by definition, the first version of something. That almost always means greenfield. But “almost always” is where founders get caught, because the exceptions are common and expensive.
The founder with nothing
An idea, a deck, maybe a prototype. No code worth keeping. This is greenfield, and it is the situation most MVP advice assumes.
If this is you, the challenge is choosing well from an open field. We covered that in how to build an MVP and the tech stack picker walks the decision.
The business adding a product
A company that already operates, with customers, a database and internal systems, decides to build a software product. The product is new. Everything it has to connect to is not.
This is brownfield, however new the product feels. The customer list lives in a CRM with its own ideas about what a customer is. Billing happens in a system nobody wants to touch. The MVP has to fit into all of it.
The founder who inherited code
You bought a company, took over a project, or your previous developer left with a half-built product and no documentation. There is a codebase. Nobody is sure what is in it.
Brownfield, and the hardest kind, because the first job is archaeology. Our post on when to rebuild your MVP is the decision this situation usually leads to.
The MVP that has to talk to something old
The product is new, the team is new, but the value depends on reading from or writing to a system that predates everyone in the room. A logistics MVP reading from a carrier feed. A fintech MVP that needs the bank’s core system.
Technically greenfield, practically brownfield, because the integration constrains everything. The build is easy. The connection is the project.
What brownfield adds to the bill
Technical discovery
Before anyone writes code, someone has to read the existing system. Not skim it: read it, map it, find the undocumented dependencies.
Two to four weeks on anything non-trivial. It feels like paying for nothing, and skipping it is how a twelve week project becomes twenty. Our product discovery engagement is the greenfield version of this; brownfield needs the technical version on top.
Integration
Connecting to what exists, on its terms. Every existing system has an API that returns slightly less than you need, a rate limit nobody mentioned, and an authentication scheme from another era.
Budget 20 to 30 percent of the build for it, and more if the system on the other side has no API at all.
Data migration
Moving what is there into the shape the new product needs, without losing anything, while the old system keeps running.
The mapping is the hard part, not the moving. Every field that means something slightly different in the old system than the new one is a decision, and there are hundreds of fields.
The regression tax
Proving you did not break what already worked. In greenfield there is nothing to break. In brownfield, there is a whole system of behaviour that users depend on, most of it undocumented, some of it accidental.
Ten to fifteen percent, and it lands at the end, which is exactly when the budget is thinnest.
A worked comparison
Same scope: a customer portal with login, order history and support tickets.
Greenfield: roughly 10 weeks, one team, $45,000 to $60,000. The cost calculator prices this shape directly.
Brownfield, plugging into an existing ERP and a legacy support system: the same 10 weeks of build, plus 3 weeks of discovery, plus integration work with two systems that do not agree on what an order is, plus migrating five years of tickets. 16 to 18 weeks, $75,000 to $95,000.
Same feature list. Sixty percent more, and none of it visible on the day the scope was written. For where the rest of the money goes in either case, see what an MVP actually costs.
The greenfield trap
Greenfield sounds like the easy one. It has its own way of going wrong.
Freedom is expensive
With every decision open, every decision gets debated. Which framework, which database, monolith or services, which cloud. Teams can spend three weeks choosing a stack for a product that does not yet have a user.
The fix is to decide fast and boringly. The MVP tech stack post is deliberately opinionated for this reason.
Nothing to test against
A brownfield project has an existing system to compare with: the new one should do what the old one did, plus something. A greenfield project has only the spec, and specs are wrong in ways nobody notices until users arrive.
The clean slate that does not stay clean
Every greenfield project is a future brownfield project. Shortcuts taken in month one are constraints inherited in month twelve, usually by the same people who took them.
That is what technical debt in an MVP actually is: greenfield turning into brownfield faster than anyone planned.
The brownfield trap
Inheriting someone else’s shortcuts
The previous team had deadlines too. What they left behind includes every corner they cut, and you will not find those corners in the documentation because the documentation was the first corner.
The rewrite temptation
Every engineer who reads an inherited codebase wants to throw it away. Sometimes they are right. Usually the old system, however ugly, encodes years of decisions about edge cases that the rewrite will rediscover one production incident at a time.
The honest version of that decision is in when to rebuild your MVP. The short version: rebuild when the old system stops you from shipping, not when it offends you.
Scope leaking in from the old system
“While you are in there, can you also fix…” The existing system has a backlog of complaints, and every one of them will be presented as part of your project.
Hold the line. The brownfield MVP has one job, and it is not fixing the old system. That is the MVP scope discipline, applied to a harder situation.
Three ways to run a brownfield build
Build alongside
The new product runs as its own system and reads from the old one through a thin integration layer. The old system is not modified.
Lowest risk, and the default for a new product that needs existing data without replacing anything. The integration layer is the whole project’s risk, concentrated in one place where you can see it.
Build on top
Extend the existing system directly. Same codebase, same database, new features.
Fastest when the existing system is well kept and the team knows it. A liability otherwise, because every weakness in the old system is now a weakness in the new product, and you cannot fix one without touching the other.
Build fresh and migrate
Greenfield build, then move the data across, then switch the old system off once the new one is proven.
The cleanest end state and the most expensive road to it, because both systems run in parallel until the switch, and the switch is a project of its own. This is the rebuild decision in its full form.
How to choose
One question settles most cases: are you replacing the old system or extending it?
Extending, and the old one is sound: build on top. Extending, and the old one is not: build alongside. Replacing: build fresh and migrate, and budget for the overlap.
Brownfield vs greenfield in practice: three real situations
The abstract distinction is easy to agree with. Here is what it looks like against actual builds.
A marketplace that was greenfield and got scoped as one
Two founders, an idea, a Figma prototype and no code. Textbook greenfield. The scope was the feature list, the stack was chosen in an afternoon from a short opinionated list, and the first working version was clickable in week six.
The only brownfield moment came later, when a payment provider’s API turned out to return settlement dates in a format nobody expected. One integration, one week. That is the greenfield ratio: almost all build, a sliver of integration.
A logistics product that looked greenfield and was not
A new product, a new team, a clean brief. Then the brief’s second paragraph: “reads shipment data from the carrier’s tracking system.”
The carrier’s system was fourteen years old, had no documented API, and identified shipments three different ways depending on which office had entered them. The build was ten weeks as scoped. Understanding, matching and reconciling the carrier’s data was another seven. The product was new. The project was brownfield from the first sentence that mentioned an existing system.
Scoped honestly at the start, that is a seventeen week plan. Scoped as greenfield, it was a ten week plan that ran seventeen, which reads very differently to a board.
An inherited codebase where the answer was alongside
A founder bought a small SaaS business with a working product, three hundred paying customers, and a codebase the previous owner had written alone over four years with no tests and no documentation.
The instinct was to rebuild. Discovery took three weeks and found the core billing logic was sound and the customer-facing interface was where every complaint lived. So the interface was rebuilt greenfield as a separate front end, reading from the existing backend through a thin layer, and the old interface was switched off once the new one had run alongside it for a month.
Brownfield, but only where it had to be. The three hundred customers never noticed the switch, which is the whole point.
How to scope each one
Scoping a greenfield build
Feature list, priorities, the one thing the product must do. The scope is the product.
The risk is underscoping the boring parts: authentication, admin, billing, the things every product needs and nobody wants to write. Our MVP requirements document template forces those onto the page.
Scoping a brownfield build
Everything above, plus an inventory of what you are building on. Which systems, which data, which users, which of them will be affected.
That inventory is the discovery phase, and it comes before the quote, not after. A brownfield quote written without it is a guess with a signature on it.
Questions to ask before you sign
- Has anyone on this team read the existing code, or only the description of it?
- Is discovery a separate, priced phase, or is it folded into the build estimate?
- What happens to the quote if the existing system turns out to be worse than described?
- Who owns the integration layer afterwards?
- What is the rollback plan if the migration goes wrong?
A vendor who answers all five clearly has done brownfield before. One who answers with “we will figure it out” has not, or has and would rather not remember.
Where PoC and prototype fit
Brownfield projects have a technical unknown that greenfield ones usually do not: can the new thing actually talk to the old thing?
That question is a proof of concept, and it should be answered before the build is scoped, not during it. We covered the distinction in PoC vs prototype. For brownfield, the PoC is nearly always the right first step, because the integration is the risk and a two week PoC on the integration is far cheaper than discovering it in week nine.
The mistakes that cost the most
Quoting brownfield like greenfield. The feature list looks the same. The project is not. Sixty percent over budget is the usual outcome.
Skipping discovery to save time. Two weeks saved in month one, six weeks lost in month three.
Rewriting because the old code is ugly. Ugly is not the same as broken. Rebuild when it stops you shipping.
Letting the old system’s backlog into the new scope. Your project has one job.
Building on top of something nobody understands. If discovery cannot explain how the existing system works, do not extend it. Build alongside.
Treating an add-on as a fresh start. A new product for an existing business is brownfield the moment it touches a customer record.
Conclusion
Greenfield and brownfield describe what you are building on, not what you are building. The feature list can be identical and the projects still nothing alike, because brownfield carries discovery, integration, migration and regression that greenfield never sees.
Most MVPs are greenfield. If yours has to plug into something that exists, it is not, and the honest move is to scope it as what it is: the same build, plus the cost of everything around it.
If you are not sure which one you have, that is the first thing to settle. We build custom MVPs in both conditions and scale existing ones, and the first call is usually spent on exactly this question. Start there.
Frequently Asked Questions
What is the difference between greenfield and brownfield software development?
Greenfield means building with nothing in place: no existing code, data or users, so every constraint is yours to choose. Brownfield means building on or alongside a system that already runs, where the constraints were chosen before you arrived and existing data and users have to be preserved. The feature scope can be identical; the project is not.
Is an MVP greenfield or brownfield?
Usually greenfield, because an MVP is the first version of something. It becomes brownfield when it has to integrate with an existing business system, when it extends a product that already exists, or when it is built on an inherited codebase. Any MVP that touches an existing customer record is brownfield in practice.
Why does brownfield cost more than greenfield for the same features?
Four things that never appear on a feature list: technical discovery to understand the existing system, integration with it on its terms, migration of existing data into the new shape, and regression testing to prove nothing that already worked has broken. Together they add 30 to 60 percent to the same build scope.
Is greenfield always easier?
No. Greenfield has its own failure modes: teams spend weeks debating decisions that brownfield would have made for them, there is no existing behaviour to test against, and shortcuts taken early turn the project into a brownfield problem within a year. Greenfield is more open, not easier.
What is a greenfield project in software?
A project that starts from scratch with no legacy system to accommodate. The team chooses the language, framework, hosting and data model freely. Most new products and most MVPs are greenfield projects.
What is a brownfield project in software?
A project that builds on, extends, or must integrate with software that already exists and is in use. Rebuilds, add-ons to an existing business, and products that depend on legacy systems are all brownfield projects.
Should I rebuild a brownfield system or build on top of it?
Rebuild when the existing system stops you from shipping. Build on top when it is well kept and the team understands it. Build alongside, as a separate system with an integration layer, when you need its data but cannot trust its code. Ugliness alone is not a reason to rebuild.
How long does a brownfield project take compared to greenfield?
Typically 40 to 80 percent longer for the same scope. The extra is front-loaded in discovery, spread through the build in integration work, and back-loaded in migration and regression testing. A 10 week greenfield build is commonly a 16 to 18 week brownfield one.
Do I need a proof of concept for a brownfield build?
Almost always. The main unknown in a brownfield project is whether the new system can actually talk to the old one, and that is exactly the kind of technical question a two to four week proof of concept exists to answer before the full build is scoped.
Can a greenfield project become brownfield?
Every one of them does, eventually. The moment a greenfield product has users and data, the next change to it is a brownfield change. How fast that happens depends on the quality of the early decisions, which is what technical debt is measuring.
