1. The Core Problem: The Psychology of Inaction
When we talk about anthropogenic climate change, we’re not just talking about a technical problem of how to reduce greenhouse gas output or recycle more plastic bottles. We’re talking about a psychological one. Per Espen Stoknes, in What We Think About When We Try Not To Think About Global Warming, identifies the "Five D's" that block engagement. Two of these are foundational to the problem Climate Cents was built to solve:
- Distance: The problem feels geographically and temporally distant. A melting ice cap is abstract. It's not in my backyard.
- Doom: The narrative is one of apocalypse. This "apocalypse fatigue" doesn't spur action; it triggers paralysis, helplessness, and disengagement.
The result is a public that is broadly aware but passively anxious. The problem is too big, too far away, and too terrifying to act on. And for some, it all smacks of either do-gooder softheadedness or more sinister forces trying to control our behavior.
2. The Product Hypothesis: Localize and Simplify
Climate Cents was the hypothesis to short-circuit this psychological gridlock formed by founders Fred Kramer and Nick Karno.
If we could shrink the problem space from "the planet" to "the neighborhood," could we defeat "Distance"?
If we could reframe action from "solve global warming" to "fund this local solar panel," could we defeat "Doom"?
The engineering thesis was straightforward enough: create a platform that connects citizens to vetted, tangible climate projects in their own communities. The mechanism would be microdonations, turning overwhelming anxiety into a simple, repeatable, and positive action. This approach directly leverages Stoknes's solutions (the "Five S's"):
- Simple: Make the action frictionless. Find a project, donate a few dollars.
- Social: Show that your neighbors are also participating, creating a norm of local engagement.
- Supportive: Frame the action as positive and empowering, not as a sacrifice.
3. The Platform: Architecture & Execution
As the sole developer, I architected and built the entire platform using a pragmatic Ruby on Rails stack. The goal was rapid prototyping and validation of the core user flow: Discover -> Vet -> Donate -> Share. Rails was a natural fit because of the ease with which a solo developer can create a rich, robust full stack application.
Why Ruby on Rails?
3.1. Speed of Development (Time to MVP) When you're trying to validate a product hypothesis—in this case, "Can local, simple microdonations overcome climate change paralysis?"—your single most important metric is time-to-learning.
Rails is famous for its "Convention over Configuration" philosophy. This means I didn't have to spend time making lots of small decisions about architecture, file structures, or database mappers. Rails provides strong, sensible defaults for 90% of what a web application needs.
This allowed me to focus on building the features that mattered—the project discovery, the donation flow, and the admin vetting system—instead of building boilerplate plumbing.
3.2. The Power of the Gem Ecosystem For a complex platform (a three-sided marketplace), I needed:
User Authentication: Handled in minutes with the Devise gem.
Payment Processing: Integrated quickly using the Stripe gem.
Admin Panels: Built a robust back-end for vetting projects with ActiveAdmin.
Image Handling: Managed project photos easily with ActiveStorage, including uploading to the cloud, compressing, cropping, name formatting, creating thumbnails and multiple size rations, and retrieving.
Content Management System (CMS): When a Rails app is stood up by-the-book, you get a CMS for nearly free, and when combined with Devise, you can easily separate roles for access control to the backend.
This mature ecosystem meant I was standing on the shoulders of giants. I could assemble a secure, feature-rich application from battle-tested components rather than writing everything from scratch.
3.3. Full-Stack Cohesion (The "Majestic Monolith") As a sole developer, managing two separate codebases (e.g., a React frontend and a Node.js API backend) is a significant tax on cognitive load. I won't go into some of the overhead involved when you get a pile of node packages needed to run a single page application, but will just say that ecosystem is incredibly helpful, rich, and varied, but when it breaks it is pure pain to troubleshoot and repair.
Rails is a full-stack framework. It provides a single, cohesive environment for everything:
Database (Active Record): A powerful and intuitive ORM.
Backend Logic (Action Controller): Clear, well-structured controllers.
Frontend (Action View): Simple, server-rendered views.
This "monolithic" approach is dramatically simpler to develop, test, and deploy for a single person. It keeps the entire application logic in one place.
3.4. Readability and Maintainability Ruby prides itself on being a language optimized for developer happiness and readability. The code reads almost like English. When you're the only person working on a project, coming back to a file you wrote three months ago and being able to understand it immediately is a massive, often underrated, advantage. It is also quite easy to create unit tests, critical for me since I did not want those midnight calls about the site falling over.
The demands of the project design also favored Rails over JavaScript-based frameworks because I needed authorization, payment, secure storage, templatized project creation sending and pulling assets from AWS S3. There were ready-made Ruby gems and Rails patterns I could use to provide a battle-tested foundation for our features without a mountain of other dependencies being brought into the project.
In short, Rails was the pragmatic choice. It's a framework built for soloists and small teams to build and ship complex applications fast.1 It allowed me to function as a much larger team and get the product in front of users to test the core idea, which is the entire point of an early-stage project.
The platform architecture was designed to manage a three-sided marketplace: citizens (donors), local non-profits (project owners), and admins (vettors).
Because I was handling lots of transactions that needed to be categorized into tax-deductible donations, postgres provided a rock solid foundation for storage and in-app reporting. Users wanted to see their tally of donations for the year and where the donations went.
The entry point for this flow was the homepage, which went through several iterations. The V3 design focused on removing all friction and immediately answering the user's primary question: "What projects are near me?" It also responded to other questions such as "How will my small donation make a difference?" and "Are there other interesting projects near me?"
4. The User Experience: From Story to Signal
This wasn't just a donation platform. It was a machine for changing the user's narrative. We were shifting the Story (another Stoknes "S") from "I am a helpless individual" to "I am part of a community solution." It shifted the scale of problem-solving from the entire Earth to your neighborhood.
The design process was about finding the most effective way to tell this new story. The designer and art director Ken Thelian explored multiple layouts for how users would discover and interact with project data. We wanted to keep word count to a minimum and provide lots of beautiful images and interactive elements such as donation status tracking and emails kicked off by the donation.
The most critical component of this narrative is the Project Detail page. This is where the hypothesis is won or lost.
This page provides the final, crucial "S": Signal. Stoknes argues that we need feedback loops to reinforce behavior. When a user donates, they aren't just sending money into the void. They are funding a specific line item—"10 trees for this park" or "one solar panel for this school." The project detail page is that signal. It makes the impact tangible, visible, and immediate.
5. Retrospective: A Tool for Behavioral Change
Climate Cents was ultimately an experiment in applied behavioral psychology, manifested as a Rails application. It was built to test the hypothesis that by making climate action local, simple, and tangible, we could bypass the psychological barriers that prevent mass engagement. It reframes the user from a passive, anxious spectator to an active, empowered local stakeholder.
The Climate Cents organization continues its mission today, having funded a number of impactful projects throughout Southern California.
On our launch day on Earth Day, our little four person nonprofit had over 40,000 visitors. As a solo engineer working under a number of constraints, the site not collapsing under that weight was a quiet victory I am still proud of.