tedpower's comments

So cool! Chris is a wizard.

Hey HN, we're YC S22 — let us know if you have any questions or feedback!

Thanks Ashwin. And if anyone has questions about working with Stripe BaaS, happy to chat about that as well — it's been great!

Thanks for the question!

So the way that Bend works, we take a transaction, and then match it with the best available 'emissions factor'. So, for example, if you purchase something at Starbucks, we match that transaction to the Starbucks specific emissions factor: https://bend.green/starbucks

Over 65% of total market cap is now covered by this sustainability data, and we aggregate that data, and use it to estimate the emissions for each transaction.

Of course there is a very long tail. So if you buy a coffee at a small coffee shop, we likely don't have that merchant-specific data. In those cases, we fall back to "Merchant Category Code" (MCC) emissions factors.

And finally, in some cases we have SKU-level data. E.g. we have an Amazon Business integration where we get the actual specific item data.

Long story short is we have surprisingly high merchant coverage — well north of 60%. We have pretty limited SKU-level coverage today, but expanding. And then we always have an MCC fallback. The larger the merchant, the more likely we are to have good data for them (we're trying to grow coverage for mid market and smaller businesses with Bend).

This means that you can get a pretty detailed, totally automated sense of your emissions hotspots.

More info here: https://usebend.com/how-it-works

Thanks :)

Hi HN, let us know if you have any questions!

haha indeed — but actually, this is kind of the point — purchasing carbon removal credits is just like any other business purchase, but with a negative emissions factor. When you purchase carbon removal credits on Bend, it shows up as just another transaction, but with negative CO2e.

Thanks, ya, fair points — as orgs level-up and get more sophisticated, you might start to use Bend as the first pass, identifying hot-spots, and then doing deeper dives on the specific 'SKUs' that are being purchased.

ya, that's right, good point. For complete GHGP inventory reporting, customers need to estimate employee commuting separately (and we're happy to help with that; it's usually a pretty straightforward calculation, though gathering the employee info takes some doing).

Setting the GHGP aside, my own personal opinion about how we interpret GHGP data is that it's important to make a clear distinction between upstream emissions and downstream emissions. For example, 'use of sold products' (Category 11) is also not something you can determine from spend data. But I'd argue that 'use of sold products' is a very different thing than upstream emissions (even though they're all lumped under Scope 3).

Commuting is a less clear-cut case, but I think of commuting (that is paid for by employees) as more of a downstream emissions category.

We wrote up some notes on this here: https://bend.green/faq/downstream-emissions

We treat payroll as zero emissions. The responsibility boundary of a company doesn't include the personal consumption decisions of employees. The spend-based approach makes this pretty straightforward — if the company is buying, those are company emissions. If an individual is buying, those are individual emissions.

Hi! Ya we only use full GHGP inventory data. Honestly, the hardest data to gather is clean transaction data! The Brex API returns relatively clean data. Other banks and financial institutions, via Plaid, often have pretty messy merchant and category info. If I had a magic wand, it's actually the spend data I'd focus on — super clean, itemized transaction data would be amazing.

We picked a price that opens up the addressable market beyond late stage and public companies.

As startups, you have an unfair advantage — it’s much easier to build good carbon habits early, vs. retooling your business after having already invested large amounts of capital in carbon-intensive practices and depreciating assets.

We do offer enterprise pricing for API access for larger customers.

Hey, good questions! You know your stuff.

Re: do you have any concerns that your users might shortcut the work to produce high quality estimates of their Scope 3 emissions when you have made it so easy to get lower quality estimates?

> I think the high order bit here is that 99%+ of companies don't measure their emissions at all. This is for a good reason — measuring your emissions historically has been quite labor-intensive. Even for large companies, there is always a 'long tail' of 'Scope 3 goods and services' transactions that are hard to measure. Our goal is to create a scalable solution so that a much larger share of companies are able to participate.

Re: your grocery store example —

> This is a fair point. Our main belief is that realtime, actionable data trumps perfectly attributed data, if perfectly attributed data requires a bottoms-up manual model. The advantage of the spend-based approach is that (1) it's realtime, and (2) it aligns incentives at the company level. The holy grail, however, would be itemized spend data (level 3 data), where you could factor in the emissions of your specific line-items. Unfortunately, that data is nearly impossible to get (yet). Maybe that's Bend 2.0 :)

Re: re-accounting historical emissions —

> Yes! We use the emissions 'factor' that most closely matches the transaction date. So for example, if you bought a Starbucks coffee in 2020, we would use the 2020 Starbucks factor, and if you bought a Starbucks in 2021, we would use the 2021 Starbucks factor. If Starbucks is late to publish their 2022 report, we would recalculate the emissions when the info is updated. For our category fallbacks, we also take currency / region into consideration.

Happy to chat more, either with you or the WRI folks! Thanks for the questions.

Unfortunately 'spend less' is not by itself a viable strategy for most growing companies. Companies need to invest in their growth. But companies can instead shift their spend from higher 'carbon intensity' goods and services to lower carbon intensity goods and services. E.g. if you need to buy a vehicle, buy an electric vehicle. Or if you need to rent office space, rent well-insulated efficient office space. Or if you need cloud hosting, select the greenest cloud and the greenest region. Or if you need to meet with a prospective customer, maybe do it over Zoom vs. getting on a plane. We try to help you prioritize that list of lower-carbon options.

Ya, the Greenhouse Gas Protocol — https://ghgprotocol.org/ — is the universally accepted way for companies to measure their emissions. It's been around for about a decade.

That being said, the Greenhouse Gas Protocol reporting has been pretty inconsistent in the past. Companies cherry-pick and leave out important info, or define their 'reporting boundary' in inconsistent ways. One of our goals is to help 'debug' these inconsistencies.

Lucas Joppa from Microsoft laid this out quite well here: https://www.ted.com/talks/lucas_joppa_how_to_fix_the_bugs_in...

Ya totally! Another way to think about it — in climate lingo, there are 3 types of emissions: First there are Scope 1 emissions, which are the emissions from burning fossil fuels directly (gas in your car, natural gas for your stove, etc.). Then there are Scope 2 emissions, which are from energy (you buy electricity from utilities, and those utilities use some percentage of non-renewable generation, like coal or natural gas). And finally Scope 3 is everything else — all the goods and services you buy, upstream and downstream.

But I think the point you guys are making, is that actually everything is Scope 1 emissions plus some number of hops. So if you buy gas, that's 0 hops. If you buy energy from your utility, and they use natural gas, that's 1 hop. If you buy an ice cream that was made in a factory powered by natural gas, that's 2 hops. And if you buy that ice cream with a cone, purchased by the ice cream shop, that was manufactured in a factory ... etc.

The problem is, consumers are often the ones who apply the pressure to address climate (don't wait for the fossil fuel companies to take this on themselves). And so we need to trace back all those upstream emissions, all the way back to those Scope 1 emissions, to really size the impact, and align incentives to decarbonize.

Historically, climate programs only focused on Scope 1 and Scope 2 emissions. But that only addresses maybe 20% of emissions for most companies. This is why it's critical to consider the impact of all the goods and services your company purchases.

+1!

Ya I hear you, our goal is to combat greenwashing in a few ways. We cover total emissions (vs. cherry-picking categories of emissions). We incentivize companies to take action today (vs. vague 2040 or 2050 goals). And to the degree that carbon credits are part of your strategy, we push for very high cost-per-tCO2e removal credits ($100 / tCO2e) vs. low quality $5-$10 cost-per-tCO2e avoidance credits.

Ya good point — our approach is always spend-based, so the way we'd calculate cloud spend is your AWS / GCP bill * the AWS / Google carbon intensity (what we call a 'factor'). It is true that some data center regions use cleaner energy vs. others. We consider the spend-based approach, at a minimum, a good first pass. The greener the cloud you use, the lower the emissions. And then you can further optimize within your cloud provider.

Another note — most cloud emissions only factor in the energy footprint ('scope 2' in technical greenhouse gas inventory terms). We believe this significantly undercounts emissions, because it ignores the capital expenditure of building the facility, buying all the machines, etc. The great thing about the spend-based approach is all this overhead is factored in. (BTW, Google Cloud Platform just started to layer in some of this 'scope 3' operational overhead data, but I believe AWS still ignores it, significantly undercounting emissions).

PlanetScale is an awesome DB that handles sharding and size-balancing — plus they have an incredible free tier. https://planetscale.com/

Rust is a memory-safe systems programming language that has earned the title of most beloved language on StackOverflow’s annual developer survey for the past six years running. https://www.rust-lang.org/

These two technologies seemed like a match made in heaven. The best in database technology with an unbeatably fast and secure access layer. There was just one problem…

…no one had ever done it before. Until now! Let us know if you have any questions :)