With Earth Day coming up on April 22nd, I’ve been thinking a lot about how we move past "greenwashing" and into actual, verifiable action.
I just published a deep dive on how to bake sustainability directly into your product DNA. If you're building in public, your users don't just want a tool - they want to know their subscription is doing some good in the world.
The 2026 theme is "Our Power, Our Planet" - a call to shift away from performative posts and toward systemic change.
Read the full breakdown and technical guide here:
👉 Earth Day 2026: How to Integrate Impact at Scale
I’d love to hear from other founders: Are you doing anything specific for Earth Day this year, or do you prefer year-round automated impact?
Drop a comment below! 🚀
#buildinpublic #saas #sustainability #earthday #indiehackers
Nice approach — tying impact to real user actions makes it feel meaningful, not just marketing. I have seen users trust products more when they can actually see the outcome.
Love this — we started adding small “impact per signup” actions in our SaaS and users actually noticed it more than features. Simple + transparent really works.
Nice idea tying impact to real actions makes it feel more authentic.
The “show your receipts” part is really interesting
This is a brilliant architectural approach. Moving sustainability from a static 'footer badge' to an event-driven product feature is definitely the future.
Tying the impact directly to a Stripe webhook (like invoice.payment_succeeded) is a very elegant solution. Having spent a lot of time recently architecting robust Stripe webhook integrations for B2B systems, I have one technical tip for anyone implementing this: make sure your webhook listener handles idempotency correctly!
If Stripe retries a payload due to a network timeout, you don't want your system to accidentally trigger (and pay for) two trees instead of one. Offloading that 3rd-party API call to an async queue while maintaining a strict idempotency key registry is usually the safest bet.
To answer your question: I definitely lean towards year-round automated impact. When it's baked into the core business logic as you described, it scales naturally with the company's MRR. Great read!
Interesting approach. Curious if there is claim validation and transparency around actual action taken from the selected causes? I assume the donations /credits go to organizations - would be nice if there is a mechanism to bring transparency to their work.
This is a smart approach — bake impact into the product, not just a blog post.
Most SaaS 'green' initiatives feel like an afterthought. A badge on the footer. A one-time donation. What you're describing (API-driven, event-triggered, verifiable) turns sustainability into a product feature, not marketing fluff.
Quick questions from a product perspective:
Curious if you've seen measurable results from the 'Show Your Receipts' model.
Appreciate the technical breakdown — rare to see this level of depth on sustainability.
This is a great take — especially the “show your receipts” part.
I think one underrated angle here is behavior.
A lot of products now make it easy to trigger impact (like planting a tree on signup), but the harder part is getting people to consistently follow through on meaningful actions over time.
That’s something I’ve been thinking about while building DealUp — turning intentions into actual commitments with social accountability.
Because even with the right tools, most people don’t fail due to lack of awareness — they fail because nothing is at stake.
Curious how you think about that layer:
👉 Do you see more value in automated impact, or in changing user behavior directly?
The "show your receipts" framing is the right instinct.
Sustainability claims without verifiable data have trained
users to be skeptical, so the transparency angle is
genuinely differentiated.
The Stripe webhook trigger is a clean implementation —
tying impact directly to revenue events makes the
connection tangible rather than abstract.
As a solo founder, I haven't tied Esprit Code to
environmental actions yet, but the API approach you
described makes it more approachable than I expected.
Worth exploring for the next milestone.
The real danger isn't what's IN the contract — it's what's NOT. No termination clause? No liability cap? Red flags hiding in the white space. Always worth the lawyer fees upfront.