Carbon Yield: Cultivating regenerative agriculture
A data platform to align economic incentives for regenerative agriculture practices; bootstrapping from Google Sheets to Airtable to custom web application.
The context
Food is responsible for a huge percentage of our global carbon footprint. The reasons are myriad: tractors and other farm equipment guzzle fossil fuels, cows belch methane, forests are cut down for grazing and cropland. As always, there are many many pieces to the puzzle, and today we’re diving into one specific solution: regenerative agriculture.
Regenerative agriculture is a collection of farming practices that improve soil and ecosystem health. They can reduce greenhouse gas emissions and improve climate resilience.
The problem
“Despite all the benefits of regenerative agriculture, only a small percentage of U.S. farms have adopted regenerative practices—in part because U.S. farm policy does not prioritize them”
—National Resource Defense Council, Regenerative Agriculture 101
In fact, there’s a growing ecosystem of incentive programs and carbon markets that seek to monetarily reward regenerative agriculture, but there’s still a disconnect in getting farmers to actually enroll.
The solution
Carbon Yield is innovating to create an agricultural economy where farms and farmers are sustained not only by crops they grow, but how they steward working lands. Their platform aligns the economic incentives, helping farmers access new revenue streams (like carbon markets) for implementing regenerative crop management practices, building a healthy and profitable growing system.
Carbon Yield bridges the gap between farmers, who need to focus on the day-to-day of running their farms, and incentive programs, which require meticulous records and detailed data inputs to convert regenerative practices into monetary rewards.
As an example, say that Farmer Bob has been using conventional farming practices for the last 20 years. Through Carbon Yield, Bob learns that he can enroll in an incentive program that will pay him cash to start implementing cover crop rotation and maintain this practice for the next 10 years. Carbon Yield collects the 20 years of historical data from Bob and submits this data to the incentive program, along with yearly updates throughout Bob’s enrollment in the program. Bob gets paid out based on the acreage converted and his ongoing adherence to the regenerative practices.
The software
At its core, the Carbon Yield platform is about farm data. They collect detailed historical and ongoing records on farm management from their clients, massage these into a standard format, and then feed this data into external carbon modeling platforms.
When we first contracted with Carbon Yield, they had been pushing Google Sheets to its absolute limits, maintaining tens of thousands of rows of farm records. They had done an admirable job of creating a relational-ish database, but they were starting to feel the pain of managing this size of data without the guardrails of a true database. They were also employing the startup best-practice of finding product-market fit through a “wizard of oz / man behind the curtain” platform - i.e. using humans for manual data collection and input. This is an excellent way to test out products quickly without wasting months and thousands of dollars building out custom software. However, they had grown their customer base enough that this manual upkeep was becoming a pain point.
Over the next couple years, as they bootstrapped their funding, we were able to help Carbon Yield transition first to Airtable, and then on to a custom web app.
Design spike
Our initial engagement with Carbon Yield was for a scoped, week-long “Design Spike” sprint. In the collaborative kick-off meeting, we worked together to build a crisp outline of their most pressing problem(s):
Time-consuming & error-prone manual data input processes
Growing pains with Google Sheets “database”; some data “mastered” in external modeling programs
No tangible software product to show clients and investors
We then spent the week building a document of possible solutions, outlining pros, cons, and cost. At the end of the week, we collaboratively reviewed the options and helped select the best fit for them. Though significantly more in-depth, this list included a subset that looked something like this:
Problem #1: manual data input
Option 0: Continue manual data input for now
Option 1: Build a farmer-facing low-code data input form
Option 2: Build a custom web app with farmer friendly data input
Problem #2: data storage / ownership
Option 0: Stay on Google Sheets for now
Option 1: Move to Airtable
Option 2: Build a custom database
Though they ultimately wanted to build a custom web app, they decided that the best interim solution would be to continue their manual processes for now (Option 0 for Problem #1), and invest in data ownership through building a robust foundational data model and transitioning to Airtable (Option 1 for Problem #2).
Want to learn more about our Design Spike method? See our previous post:
Data model + Airtable
One of the key points we identified during our Design Spike was the importance of solving the “data ownership” problem. Carbon Yield collects data from many farmers, who each have their own way of keeping records, and then inputs this data into several different external carbon models, which each have their own data input requirements. In some cases, they bypassed their own Google Sheets and only recorded farm data within an external system. We counseled Carbon Yield to develop their own data model and to consider their own records as the “source of truth,” to be later converted into the particular input shape required for external programs.
Thus, the next phase of our work involved working closely with them to design their core data model, expressed relationally. Their existing Google Sheets were a solid foundation for this, but we were able to tighten up the table definitions and relationships according to best practices. We then configured an Airtable base for them expressing this data model, and they migrated all their data from Google Sheets into Airtable. Progress!
For the time being, they continued to do manual data input, but now with strictly enforced entity relationships, nicer UI for data input, and much better guardrails against human error.
Custom web application
Airtable served them well for a year, as they continued to grow their customer base and raise capital. When they came back to us, they were ready to fund some custom software.
At this point, we brought a few more folks onto the team, including Tiana Veldwisch, the former Director of Carbon Product Management at Indigo Ag, with highly relevant domain expertise in agricultural software.
The initial framing from Carbon Yield was roughly as follows: build a custom web app where farmers can input their own data.
Rather than blindly implementing a product as requested, it’s Option Zero’s practice to take a step back and dig into the problem space first.
We saw the opportunity to pull out two of our favorite software design tools:
User personas
Reframing the problem
Software design tools
User personas
In our very first engagement with Carbon Yield, one of the things they stressed was that farmers are often tech-skeptics, and that getting them to engage with any new software can be like pulling teeth. Carbon Yield’s consulting model was to collect the required data from farmers through direct phone calls. A Carbon Yield admin would interview the farmer about their historical crop management practices, record the answers in long form, and later manually input into their database. This consulting model had been successful at least partly because the 1:1 relationship and availability built trust, and didn’t require the farmer to learn or interact with some new software system.
Given this, and the natural complexity of the data, we suspected it would be quite difficult to build a data input product that farmers would be willing to use. We worried that anything we built would just gather dust, and CY admins would still have to manually chase down farmers by phone to extract the required data.
Reframing the problem
Though the original ask was to build a farmer-facing data input product, as we clarified the underlying problems that resulted in this particular solution request, we got two answers:
It’s taking too long for our admin users to interview farmers and then manually collate the data into the correct form
We want to have a “tangible” software product to build trust in our system, both with our farmer clients, but also with potential funding sources.
This reframing suggests many solutions that don’t necessarily involve building a farmer-facing input form.
In this case we proposed that we instead build admin-facing software that allowed Carbon Yield admins to collect and input the necessary data much faster, ideally while actively on a phone call with a farmer. We could then build a much simpler read-only interface for farmers to view that data.
Admin UI v0 & v1
With this foundational design question resolved, we architected a custom web application for their admin users, focusing on building UI that allowed admins to rapidly input data while on a phone call with a farmer.
We replaced Airtable with Supabase, a backend-as-a-service. Supabase has the advantage of functioning as a true cloud-hosted Postgres database, while also providing an acceptably functional admin user UI for standard CRUD operations. In fact, we chose to refer to Supabase itself as the “Admin UI v0,” which gave us the mindset that our custom “Admin UI v1” did not have to be fully featured. Our custom web app only needed to support specific use-cases that were relevant for rapid data entry during a farmer interview.
We built out this custom frontend using Redwood, Typescript, & React.
We considered this app to be a complete “Minimum Viable Product” (MVP), even though it wasn’t farmer-facing at all!
Farmer UI v0
When Carbon Yield was ready to fund another tranche of work, we were able to quickly build out a farmer-facing view-only UI. This UI focuses on presenting the data in the way farmers are most likely to think of it, and live-updates with new admin data input. This way farmers can view and validate the correctness of the data while actively on a phone call with an admin.
In conclusion…
This case study highlights the importance of balancing the right level of build with the evolving need. It’s about finding the sweet spot of high-bang-for-buck problem-solving that moves the product forward without over-engineering or breaking the bank. It’s always tempting to jump right to building out fully-fleshed custom software, but often it’s better to take smaller, more iterative steps.
Initially, the most pressing need was around solidifying the data structure and preventing human error. We were able to deliver a low-cost interim solution on Airtable that not only solved the client’s immediate issues, but also served as a critical foundation for future work.
As the product (and budget) evolved, we were able to make tactical, iterative improvements, first with admin-centric data entry, and later with farmer-facing UI.
“What was notable and fun about this collaboration was bringing together a diverse team to make it happen. Different expertise and backgrounds but shared values gave us incredible results. The staged flexible approach really worked for us as a startup even if it is a less traditional path—it gave us a strong financial basis to spend hard earned capital to make compelling internal change and efficiency gains.”
—Claire Pluard, Carbon Yield COO & Co-founder
Just like in regenerative agriculture where you want to do the interventions that best preserve the soil's nutrients for long-term success, a collaboration like this uses resources in a meaningful-for-the-moment way to support future growth.
