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):

1. Time-consuming & error-prone manual data input processes

2. Growing pains with Google Sheets “database”; some data “mastered” in external modeling programs

3. 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:

1. User personas

2. 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:

1. It’s taking too long for our admin users to interview farmers and then manually collate the data into the correct form

2. 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.

EnergySavvy was a SAAS company focused on residential energy efficiency projects. After we left, EnergySavvy was acquired and merged into what is now Uplight. The products we worked on evolved into some of Uplight's foundational services, including Next Best Action and Digital Customer Engagement.

Jason built the team and product for Quantify, EnergySavvy's first "big data" endeavor. The project involved modeling home energy savings at utility scale to close the feedback loop on energy-saving measures.

The context

“Energy efficiency is one of the easiest and most cost-effective ways to combat climate change, reduce energy costs for consumers, and improve the competitiveness of U.S. businesses. Energy efficiency is also a vital component in achieving net-zero emissions of carbon dioxide through decarbonization.”

- U.S. Department of Energy

Aaron Goldfeder, the CEO of EnergySavvy, puts it even more concisely:

“The cleanest energy is the energy we don’t use.”

Like our previous case study on Energy Raven, EnergySavvy focused on a tiny sliver of the climate problem: energy inefficiency (overuse) in residential buildings. However, EnergySavvy worked directly with utility companies to help them manage their energy efficiency retrofit programs.

If you consider this for a moment, you may wonder: why would utilities, which sell energy, try to help their customers to buy less energy?

In the U.S., public utility companies are a strange beast: semi-privatized, semi-public, heavily regulated, government-sanctioned monopolies. Their economic incentives are often backwards from what you might reasonably expect in a normal supply-vs-demand-driven capitalist market. Utility companies ostensibly sell a product (electricity) to customers (residential and commercial building owners). As such, you’d expect them to be incentivized to maximize sales, i.e. get electricity consumers to consume more electricity. However, due to a combination of enormous capital outlay to increase capacity, and closely-monitored regulations capping the price they can charge for their product, utility companies are often instead incentivized to employ Demand Side Management (DSM) strategies, to reduce energy demand or at least shift it from peak hours. DSM practices include subsidizing homeowners in performing energy efficiency retrofits on their home—think improving insulation by adding weather stripping, replacing an old inefficient refrigerator with an Energy Star-certified one, or upgrading the HVAC system to use a heat pump.

The problem

There’s an interesting question here. If a utility helps thousands of its customers perform these energy efficiency upgrades, how do they know how much energy was saved as a result?

In data science, this is a classic “counterfactual” problem. How do you know how things would have been different if you hadn’t made a given change? How do you know how much energy you didn’t use?

In the utility world, this question is more than just philosophical. Utilities are required to participate in Measurement & Verification (M&V), a “process of planning, measuring, collecting and analyzing data to verify and report energy savings within a facility or facilities, resulting from the implementation of energy-efficiency measures”—Bonneville Power Administration

The solution

EnergySavvy built a software product that applied cutting-edge machine learning (ML) to automate this M&V process—this automation is known in the industry as “M&V 2.0.” The product slurped up utility-scale energy usage data and fed it into an ML pipeline to “calculate” how much energy was saved by a given energy efficiency treatment.

Savings Measurement 101

The basic approach to savings measurement is:

1. Collect energy usage data for a pre-treatment period (say, for the year before you install your new heat pump).

2. Create a model of each home before treatment. This is your baseline model. The model1 is trained with your pre-treatment data to predict the amount of energy used by the baseline home under a variety of conditions. The most important input to this model is weather data, since HVAC systems account for most of a home’s variable load.

3. Collect energy usage data for a time period after treatment.

4. Run your baseline model, which represents your unmodified home, with your post-treatment weather conditions to estimate how much usage the home would have used in the post-treatment period, if it hadn’t had the treatment (in this case, the new heat pump).2

5. Finally, measure your savings by taking your actual post-treatment usage from step (3), and subtracting your modeled usage from step (4).

energySavings = actualEnergyUsagePostTreatment - modeledEnergyUsage

Boom. Easy, right?

It’s not that easy

While the 101 method above can get you a crude estimate in ideal conditions, it’s not robust enough to “take to the bank” - or to regulators. To be useful, you need to account for factors such as:

Drift

Drift is an issue in Machine Learning in general; it occurs anytime that you build a model with data from a given time period and then use it in a later time period. Factors that underly the model are expected to remain constant, but in reality they can and will drift. One common culprit in residential energy efficiency is macroeconomic factors—for instance, in the 2008 recession, energy got more expensive and everybody tightened their belts and used less energy. If you naively used the formula above, it would look like everybody had a highly effective energy intervention.

Luckily, statistical tools for this abound. Models for this date at least back to the 1980s with the Princeton Scorekeeping Model (PRISM), which prescribes using a control group of homes to compensate for population-wide drift factors:

The general gist of this is the same as any controlled trial:  you create a “control group” out of a population that didn’t receive a treatment (in this case, similar homes that did not get a heat pump installed) and compare the outcomes from the treated group with the outcomes of the control group.

Model uncertainty

You may have heard the adage: All models are wrong; some are useful.

No energy usage model can account for every factor affecting energy usage, so any savings estimate has limitations. It can be tempting to ship a model without studying this uncertainty. At the end of the day though, the difference between a useful model and a useless one is how well you understand its limitations. At EnergySavvy, we developed a machine-learning-based approach that allowed us to build a customized uncertainty model for each home, simultaneously compensating for drift.

With a robust understanding of model uncertainty, we were able to assess which types of retrofits were performing better or worse, and which might be average or on a “watch” list.

…and there’s more

Beyond these, a utility must consider other factors, including free ridership and the rebound effect, to take credit for any improvements it subsidizes.

The software

From a software perspective, once you have all of the above figured out, it’s just a S.M.O.P.—Simple Matter of Programming. Plug the data into the algorithms and turn the crank!

Just make sure you get these things right:

• Observability & provenance: When something weird shows up in the results, you’ll want to be able to explain it. For the Quantify product, we instrumented our data pipeline with a wide range of diagnostics from end to end, so that we could understand the effects of any code change that we made.

• Big-ish data: utilities often have customer counts in the millions. When processing multiple years of data for each home, the GBs start to add up. While you don’t necessarily need to use heavyweight map-reduce or streaming machinery to get the job done, choosing your data stores appropriately and avoiding reprocessing can pay dividends here.

• Compute costs and timing: Operational cost is a minor issue in many software applications. What’s $30 per month in operational costs when you’re paying an engineering team? With the big-ish data and complex algorithms, comes the potential for substantial ($1000 per month and up) compute costs. In addition, processing large amounts of data can take real wall-clock time, constraining your ability to iterate and deliver quickly.

• Error handling (or Murphy’s Law as applied to Data): Everything that can go wrong with the data, will go wrong with the data. In practice, this means you want off-ramps in your data pipelines, where problematic or outlier data can be flagged for analysis without bringing the system to a screeching halt.

In conclusion…

The cleanest energy is the energy we don’t use. At EnergySavvy, we put the “efficiency” into energy efficiency by helping utilities roll out optimized programs supporting residential energy efficiency at scale.

Osmo Systems was a seed-stage climate tech company aiming to make aquaculture more sustainable when they hired us on as their software engineering team.

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 this puzzle, and today we’re isolating one specific sliver.

In Should We Eat Meat?, Valclav Smil dissects the titular question with his customary exhaustive detail, considering the human body’s need for high-quality protein alongside the deleterious environmental consequences. And his conclusion is similarly complex—he recommends “‘rational meat eating’, where environmental and health impacts are reduced, animals are treated more humanely, and alternative sources of protein make a higher contribution.”

One such rational choice is shifting some meat consumption away from high-carbon-cost cattle in favor of lower-carbon seafood (both wild-caught and farm-raised).

(If you’re not sure of this claim, check out this insanely detailed and comprehensive article from Our World in Data on Fish and Overfishing.)

The problem

Aquaculture is crazy inefficient.

There are a variety of metrics that relate to the overall crop yield, but by far the biggest, baddest wolf is dissolved oxygen. Just like humans, aquatic life needs to breathe oxygen, but unlike us they get it straight from the water in the form of dissolved oxygen. Oxygen in water is produced in a diurnal cycle, peaking during the day when algae are actively photosynthesizing, and dropping overnight when there’s no sun to power this process.

This all feels a little academic, but I hope it hits home when I tell you that shrimp farmers in Thailand frequently (and I mean frequently) have their entire crop die off overnight, because their shrimp consumed all of the available oxygen and then suffocated. This isn’t just inefficient; this is catastrophic for their livelihood.

The insight

Facing age-old problems, modern solutions demand better data powering more targeted insights. Aquaculture is an industry ripe for better data—if these farmers had real-time water quality data with alerts when any metric fell below critical levels, they would quite literally sleep better at night.

Unfortunately, existing water quality sensors are just too expensive, and so most onshore fish and shrimp farms don’t have adequate water quality monitoring.

The solution

At Osmo Systems, we were working to develop cheaper, smarter, lower-maintenance water quality sensors, packaged up into IoT devices to power a cloud-hosted dashboard with real-time water quality monitoring, alerting, analysis, and insights.

From a software standpoint, managing a fleet of IoT devices and building a web dashboard is not entirely trivial, but certainly well within the world of known software solutions. Building this out is why Osmo Systems initially hired us on.

The hard part is the sensor design.

Osmo Systems was developing their sensor technology around small chemical patches that fluoresced proportional to the absence of dissolved oxygen (DO), i.e. the fluorescence was less bright when more DO was present. These patches are traditionally read using an expensive piece of equipment called a phase fluorometer. Osmo Systems bet on being able to measure those changes accurately enough using simpler technology, first with simple photodiodes, and later with off-the-shelf cameras.

The software

As it turned out, developing the sensors became a major R&D effort, and we, as the software team, pivoted to apply crucial acceleration to that process.

We paused work on the product prototype, and shifted into streamlining a R&D testing apparatus to accelerate the team’s ability to rapidly test new sensor designs. Our scientists and mechanical engineers built a water bath with precisely controllable temperature, pressure, and dissolved oxygen levels. We set up a raspberry pi and python script to run tests, setting the environmental conditions and collecting and storing the sensor data.

We taught our science team enough python to be able to analyze the data in Jupyter notebooks.

After reviewing the relevant scientific literature, we designed calibration algorithms to characterize the sensor’s response to dissolved oxygen and temperature, and to assess the stability of the fit over time to determine readiness of the sensor.

Despite some initially promising high-quality fits of the data to the latest models, we were eventually forced to conclude that simple image processing and standard ML regression models weren’t going to be sufficient to convert our sensor images into the data points we needed.

However, the software acceleration of this work meant it took weeks instead of months or years to identify that we needed to move on.

So, we pivoted again, this time to apply the most cutting-edge software to the problem: AI.

Specifically, we worked on training a convolutional neural network (a deep learning model subtype optimized for image processing) to predict dissolved oxygen concentration given an image of a fluorescing patch.

We built out a custom machine, jam-packed with GPUs1. We built our own models in TensorFlow, and used Weights & Biases to meticulously track and compare the performance of our various training runs.

We repurposed the R&D testbed to collect first hundreds and then thousands of images, captured alongside precise and accurate measurements of actual water quality metrics. We fed this as training data into our ravenous deep learning models.

And it wasn’t enough.

Our models failed to accurately predict dissolved oxygen across even a subset of the range of relevant environmental conditions. We were forced to conclude that there simply wasn’t enough information encoded in our images to extract the data we needed.

In conclusion..

In this case, the software team was able to vastly accelerate the company’s learning process, so that it took only months to conclusively decide that the big bet on cheap sensors simply wasn’t going to pay off.

As a result of this fast failure, Osmo was able to repurpose its remaining funds to pivot into a completely different climate solution vertical. Much of the project management DNA and software strategy that we contributed continues in the company’s current reincarnation as Carbon Collective, a climate fintech company developing stock & bond portfolios purpose-built for solving climate change.

Energy Raven is a climate tech platform with a brilliant insight on catalyzing homeowner action for home energy electrification.

They hired us to build out their 0-to-1 MVP app, so we’ve got the insider’s view into their software architecture. We helped them get crisp on the exact problem they were solving and narrow in on the minimum (!) software needed to get the job done.

Why the minimum? See our previous post:

In this case study, as in so many climate solutions, we zoom in on one specific source of fossil fuel consumption and ask: how we can make this go away?

In this case, we’re looking at direct fossil fuel consumption in residential buildings. To fight the climate crisis, we need to electrify homes and upgrade them to use less energy overall — we need to turn that little brown bar (representing 5+ quadrillion BTUs of fossil-fueled energy consumption) into blue or green!

Saul Griffith and the folks at Rewiring America have a campaign to “Electrify Everything.” The biggest 3 things a homeowner can do to fight climate change on an individual level are to: 

1. Install rooftop solar

2. Get an electric heat pump heater (bonus: electrify other appliances)

3. Drive an EV

However, despite a clear problem and concrete solutions, the residential energy transition is slow. Why?

The problem

Well, a residential energy transition requires homeowners to take action to perform these home energy retrofits, and they either:

• aren’t aware of options

• are turned off by price tag

• lack activation energy

An in-depth study into Homeowner Decision Making and Behavior Relating to Deep Home Retrofits found that: “Neither the existence of energy-saving technologies nor the capability to achieve substantial energy savings automatically translate into homeowner action”

Basically, even when homeowners know that options exist, they still need the activation energy to actually explore and make the changes.

The insight

The folks at Energy Raven had a big insight:

The home buying process could be a catalyst for home energy upgrades

This is a moment when the prospective homebuyer is looking to make a major investment, a time when they’ll be open to suggestions and have a bigger appetite for big ticket spending. They’re also likely to value information about operating costs of the home. (In the United States, operating cost information is still largely absent from home listings.)

The solution

Energy Raven produces a home energy performance report during home inspection.

In the U.S., most homes under contract receive an inspection from a licensed inspector. This inspection is focused on identifying structural and appliance issues; the inspectors are not trained to analyze energy usage.

Energy Raven fills that knowledge gap. The Energy Raven app takes what the home inspector knows and augments it, and then provides the homebuyer with information on likely home performance and potential wallet-wise and climate-saving upgrades.

This app matches a common pattern we see in climate software—building off public datasets, sprinkling in proprietary secret sauce, and wrapping it up in a modern web app. Let’s take a look!

The software

The Energy Raven app guides home inspectors to collect energy-specific data on the home and combines this with existing public and commercial datasets to generate a home energy performance report, which is presented to prospective home buyers in a web app.

The components:

1. Home inspection

2. Public data

3. Energy modeling engine

4. Web app

Home inspection

The inspector submits a completed inspection report to Energy Raven, and the software extracts the energy-relevant data points.

Public (and commercial) data

The app bolsters the data collected during the home inspection with public and commercial data available both on the specific home, and on a statistically representative spread of homes in general.

Energy modeling engine

On the backend, the collected and public data are input into an energy modeling engine. This modeling engine is itself built around a public tool: the US Department of Energy (DOE) EnergyPlus / Open Studio energy modeling physics engine. The modeling engine wraps this up in a docker container and deploys it on standard cloud infrastructure.

The modeling process is time- and CPU-intensive, and therefore runs asynchronously, notifying the homebuyer via email when the energy performance report is ready.

Web app

The energy report is presented in a fairly vanilla web app, built on React, Typescript, and Node.

In conclusion..

Combining existing (often public) datasets with proprietary secret sauce and packaging into a basic web application is a pattern we see often in climate tech. There is a wealth of publicly available climate-relevant data: weather, energy consumption and generation, land usage, and so on.

Taking public data and turning it into actionable insight is a win-win-win: for the company, the customer, and the climate!