Rewriting Regrow’s MRV platform for performance and scalability

Rebuilding a core product is never a small feat. No matter how much thought and planning goes in, it ultimately demands a large engineering investment. With a clear vision for how we wanted our MRV (measure, reporting, verification) platform to perform, the challenge became turning that vision into a reality. 

In this article, we’ll walk through how we rebuilt Regrow’s farmer-first platform to be faster, more flexible, and easier to use. We redesigned the interface and restructured the way our app connects to data behind the scenes, using modern tools to enhance usability.

Curious about our tech stack? 

We have a React application for our front-end, supported by a NodeJS + GraphQL backend-for-frontend (BFF) to deliver optimized data to the UI. Our design system is built with Material UI to create a consistent, responsive, and accessible user experience. You can learn more about our tech stack, and the decisions we made at the end of the blog.

Considerations for rebuilding our MRV platform

Before we made any changes, we evaluated our existing application, pinpointing areas for improvement. We led a series of workshops across our UI teams, aggregating our shared knowledge and desired best-practices for the future. We wanted to ensure that our app is easy to maintain and the engineering experience is optimized for velocity.

As a result of those workshops, we aligned on key goals for how we wanted to approach our rebuild.

Planned improvements for the product 

• Streamlining data loading — simplifying and speeding up how we show users their data.
• Strong automated test coverage — catch bugs before they reach users and faster feature delivery.
• Streamlining branding and design — improving usability and flow in the user experience
• Improving navigation and accessibility  — making it easier for users to move flexibly through the app.

Keeping our changes focused on users

We put a significant amount of time and consideration into our audience as we planned our platform adjustments. Here are some of the insights that guided our rebuild:

• Growers use our application in all corners of the world, often in rural areas where network speeds and reliability vary widely. Our application needs to be lightweight and performant.
• We need a cohesive user experience, and component library that can be shared across all of Regrow’s products. Accessibility, usability and a clean user-experience are pillars of our plans for a scalable application.
• Finally, it is paramount that we maintain stability throughout the improvement process. We need to make future platform changes confidently without regressions in any parts of the platform.

What does this mean for the farmers using our platform? 

For farmers, these changes and others lead to a faster, easier, and more intuitive way to enter and manage field data. The new system lets them log key activities (cropping, tillage, irrigation, and nutrient applications) in a flexible and accessible spreadsheet-style form that provides instant feedback and guidance. As they enter data, it’s automatically grouped into cultivation cycles and displayed in a clear timeline, making it simple to track progress and understand their farming history year-over-year. The experience is more accessible, mobile-friendly, and built to support the wide range of practices farmers use throughout the season.

Rebuilding an application from the ground up is never easy, but by combining deep agricultural insight with thoughtful engineering and design, we’ve created a platform that’s stronger, smarter, and more responsive to farmers’ needs. Every decision was made with care: to improve performance, enhance usability, and support the evolving practices of the growers we serve. 

We’re proud of what we’ve built, and even more excited for the upcoming enrollment season when farmers will get to experience the difference firsthand.

Learn more about our MRV.

Dive deeper: how we built this 

From a software engineer’s perspective

Curious about how this transformation happened behind the scenes? This section takes you under the hood of our rebuild—exploring the architecture, design systems, and technical decisions that made Regrow’s platform faster, more scalable, and easier to maintain. Whether you’re part of a product team or just love good software, here’s how we brought it all together.

Preparing for change with a strong foundation

To prepare our application for scale, we started by upgrading our routing to enable seamless navigation between the new and legacy views. This not only reduced the risk of regressions in the legacy components, but also allowed us to isolate our new views to support continuous rollout and testing throughout the rewrite. In parallel, we upgraded our shared components and added legacy test coverage as we developed new features.

We also refactored our container styling to support a flexible layout for all device sizes, with consistent scroll containers and a predictable stacking context. This layout refactor paired with the introduction of our Leaf design-system paved the way for many new mobile friendly experiences across the application.

Adding a backend-for-frontend service using GraphQL

The most significant challenge we faced was how we fetched and cached data. After evaluating several options, it became clear GraphQL offered the tools we needed to address our core state and performance issues. We implemented a simple backend-for-frontend service using NodeJS and Typescript, with type code generation and Jest test coverage. We chose to build our backend-for-frontend service with the same technologies we use in our front-end applications to allow seamless onboarding and reduced cognitive load for our engineers.

Using GraphQL with Apollo, we were able to implement a simple graph to support:

• A data structure optimized for front-end performance without overfetching - Queries are tailored to each view’s needs, minimizing payload size and improving load times.
• Moving data joins out of the front-end – Removed dependencies on global Redux state by handling data composition in the backend, simplifying component logic and reducing coupling.
• Leveraging Apollo’s caching layer – Apollo enables performant data refetching and makes it easy to share state across sibling components without manual plumbing.
  Automating typing with GraphQL Codegen – API responses are now type-safe by default, improving reliability and accelerating development.

GraphQL enabled key features needed to make our MRV experience feel smooth and informative. As growers enter their farming data, we use GraphQL’s inherent query reactivity to keep core components, such as our field events timeline and completion indicators in-sync. This immediate feedback to growers gives insight to how they are progressing through the data entry process.

Leaf Design system

Early on we identified a significant pain point in our front end application. We were using multiple implementations of common components, which resulted in reduced engineering velocity and introduced inconsistent UI standards.

To address these challenges, we introduced Leaf, a shared design system, with the goal of creating a consistent and coherent paradigm for visual design and component development. Our motivation was to stabilize and enhance the user experience, ensure accessibility and responsiveness, deliver new features more reliably, establish a consistent brand identity, and improve overall performance.

Leaf allows teams to focus on more complex features by providing a modern, reliable, and well-documented base framework through MUI. It supports the creation of extensible components that meet the needs of multiple teams and products, and introduces clear design-to-build processes and usage guidelines for developers. Through this effort, we aim to eliminate legacy code landmines, support sustainable squad independence, and strengthen collaboration and onboarding between design and development teams.

Leaf is built on the following principles

• Simple – we keep styles and components to a minimum so it’s easier for both users and builders to understand. 
• Consistent – using the same language, styles and components as much as possible across our products  simplifies development and improves the user-experience.
• Modular – when adding new styles and components, we consider how they will scale to other use cases.
• Accessible – accessibility improves the experience for all, not just those with disabilities.
• Usable – builders should feel confident that components are tested and user-friendly out of the box.
• Always evolving – build, test, repeat.

Cultivation Cycles and Data Grid

Our new data collection form is where all of our work comes together. This data-entry experience allows growers to view and edit their farming events, such as cropping, tillage, irrigation and nutrient applications in a flexible, performant data-grid table. Each data-entry row has their own set of validations and decorators to guide the user through entering the wide array of crops and practices that can take place in a growing season.

Along with instant feedback from form validations, the grower’s farming data will be automatically grouped by their crop and harvest year. These crop cycles intuitively group and sort related crops and practices, allowing the grower to easily see their farming history organized year over year. As they add their field data, they see an overview of their practices in their field events timeline, and will immediately be notified once the required data entry is complete.

This new data-entry experience leverages MUI’s powerful data-grid components. This gives us a performant, flexible, feature rich base to customize and includes important accessibility features such as keyboard navigation. Our data-grid implementation paired perfectly with our new Leaf design-system input components, marking a tidy conclusion to our refactoring efforts.

Approaching an app rebuild is a daunting and risky task, but the retrospective on the past two years of work is an impressive blend of architecting, design collaboration, and agricultural domain knowledge. Through careful planning and deliberate incremental changes across our application, we were able to reduce risk, limit scope, and lift the overall quality of our entire codebase along the way.  We are now better equipped to respond to grower needs, have improved the ease for adding new features, are able to rely on our automated tests, and our new codebase is generally a joy to work in. 

We are better engineers and better farmers for all we have learned about both throughout this process. We are so looking forward to the upcoming enrollment season for growers to experience the work and care we’ve put into our new MRV data entry experience!

‍

Curious about our work? Get in touch.