The Beauty of Brownfield Development

Developer Perspective
Bookmark

In software development, the term “greenfield project” is often used to describe a project that is built from clean slate. Greenfield projects often present an exciting opportunity for engineers for a number of reasons. However, the foil to a greenfield project is a brownfield project. A brownfield project is one where there is a feature built on top of existing code. With brownfield projects, engineers are often subject to the constraints of the current system and must find a way for their project to coexist alongside legacy code.

Advantages of Greenfield Development

  • Opportunity for new technology – With greenfield projects, engineers can freely pick the technologies that are the right fit for their projects. Modern technologies can provide a foundation that accelerates a project. Organizations might use a greenfield project as an opportunity to learn about new technology and see if it’s the right fit for them.
  • Unconstrained architecture – With greenfield projects, engineers can freely architect the system to focus on the problem they are solving. This is especially helpful if the project is working under different assumptions from the existing legacy systems. Efforts to rearchitect a legacy system might result in lengthy, complex, and risky migrations and these can be short circuited by choosing to rebuild the system. 
  • Faster output (but output != impact) – When engineers don’t need to worry about legacy code, that can help speed up their development output. Engineers are slowed down when they encounter surprises in legacy code. Working in a greenfield project means that they run into fewer surprises.

Advantages of Brownfield Development

  • Not having to reinvent the wheel – Before jumping into a greenfield project, it’s important to think about what value is added for each component of the project. With many greenfield projects, there are components of the system being rebuilt where the new version is not introducing anything new. Choosing to build off of an existing system would avoid the cost and effort of rebuilding those components.
  • Working with fewer unknowns – Engineers can jump into a project knowing that many elements of the project have been de-risked. Picking a new technology or new architecture is placing a bet on that approach. One of the traps of a greenfield project is that the engineers start with a belief that a new architecture or a new technology will solve a critical problem, but they end up making inadvertent tradeoffs that introduce different challenges. 
  • Faster decision making – While working with constraints can feel burdensome, it can also make decisions more straightforward. The wealth of options in a greenfield project can create some decision paralysis. Picking between a few options is typically more straightforward than picking between dozens of options.
  • Opportunity to restore what exists – When working in a legacy codebase, engineers have an opportunity to leave things in a better state than what existed before. A team working to improve a commonly used legacy system might as a side effect improve that system for many teams and not just themselves.

Building out the Gusto Embedded Payroll MVP

In 2021, Gusto introduced Gusto Embedded Payroll. This was a new product that enables software developers to embed and customize payroll directly into their software. Once we saw the opportunity we had to expand into the embedded space, the next step for our engineering team was to decide on a technical strategy and specifically we had to decide how we wanted to build the APIs and web components.

We ended up going with the brownfield approach for our APIs and payroll logic. This was an easy decision for us given the 10+ years of carefully crafted code that’s gone into the development of our payroll product. This is even more of a no-brainer when considering the domain of payroll and the incredibly high cost for the end user if we got something wrong.

However, we also decided to take a greenfield approach to our embeddable web components. This was because we recognized the need for flexibility in the system to allow for different approaches to test for many different hypotheses as it related to embedded web components. For now, our approach to embeddable web components involves an iFrameable web app, but what if we wanted to publish our own javascript library one day? Or what if we wanted to open source our frontend altogether?

As an emerging business within Gusto, we chose to focus on specific hypotheses. Focus is key for startups to succeed and the technology choices must reflect that. We chose our balance of what to build greenfield and what to build brownfield as a reflection of our best way to test the right hypotheses.

From where we started in 2021, we’ve quickly built out many core features for Gusto Embedded Payroll. This velocity has allowed us to deliver a great platform and make it easy for our customers to go to market.

Have any questions?

The Gusto Embedded Payroll team is happy to help! Simply submit your feedback or question and a member of the Gusto Embedded Payroll team will get back to you as quickly as possible!

Matt Oey Matt Oey is an Engineering lead on the Gusto Embedded team. A Gustie since 2017, Matt has held a number of individual contributor and people leadership roles in Engineering. Prior to coming to Gusto, Matt was an engineer at Google and holds a BS in Computer Science from Cornell University. During the winter, you'll often find Matt skiing off piste with Gusto!
Back to top