Most carbon footprint applications have a simple workflow:
Input your lifestyle.
Get a carbon number.
Receive a list of generic recommendations.
The problem is that awareness rarely changes behavior.
Knowing that your annual footprint is 8.2 tons of CO₂ does not automatically tell you what to do next.
That observation became the foundation for Climbit.
Instead of building another carbon calculator, I built an AI-assisted climate decision engine designed to answer a much more practical question:
What is the single highest-impact action I can realistically take right now?
This article breaks down the architecture, engineering decisions, technical challenges, and lessons learned while building the project.
The Core Idea
Most sustainability tools optimize for measurement.
Climbit optimizes for decision-making.
The platform evaluates a user's lifestyle across multiple categories:
- Commute
- Home energy usage
- Air conditioning
- Food and diet
- Deliveries
- Travel
The system then identifies where emissions are concentrated and ranks actions based on:
- Carbon reduction potential
- Cost
- Effort required
- Lifestyle relevance
- Confidence level
The objective is not to overwhelm users with options.
The objective is to surface the single most impactful next action.
System Architecture
The biggest architectural decision was separating deterministic calculations from AI-generated content.
Large language models are excellent at interpretation and communication.
They are not reliable sources of mathematical truth.
For that reason, every numerical calculation in Climbit is deterministic.
User Inputs
│
▼
Carbon Calculation Engine
(TypeScript)
│
▼
ROI Ranking Engine
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Personas Challenges Insights
│ │ │
└─────────────┼─────────────┘
▼
Gemini Layer
(Interpretation Only)
│
▼
Dashboard UI
This separation prevents hallucinated calculations while still allowing AI to provide personalized experiences.
Technology Stack
Frontend
- Next.js 15
- React 19
- TypeScript
- Tailwind CSS
- Recharts
Backend
- Next.js Server Actions
- Supabase
- Clerk Authentication
AI Layer
- Google Gemini 1.5 Flash
- Structured JSON Output
- Vision Processing
- Voice Interpretation
Quality Assurance
- Vitest
- Playwright
- axe-core
- ESLint
- TypeScript Strict Mode
Why Gemini?
The project required more than text generation.
Users needed the ability to:
- Upload utility bills
- Upload receipts
- Submit voice logs
- Receive structured recommendations
Gemini was selected because it provides:
- Structured JSON generation
- Vision capabilities
- Fast inference speeds
- Strong multimodal support
A typical flow looks like this:
Receipt Image
│
▼
Gemini Vision
│
▼
Structured JSON
│
▼
Carbon Engine
│
▼
Dashboard Update
The AI never directly calculates emissions.
It only extracts structured context.
The Carbon Engine
The heart of the application lives inside:
lib/carbon.ts
The engine calculates:
Monthly Footprint
=
Commute
+
Diet
+
Electricity
+
AC Usage
+
Deliveries
+
Travel
Once the baseline footprint is generated, actions are ranked using a deterministic ROI model.
ROI Score =
(
Carbon × 0.45 +
Effort × 0.25 +
Cost × 0.20 +
Relevance × 0.10
)
× Confidence
This ensures recommendations remain transparent and explainable.
Carbon Negotiator
One of the most interesting features added during development was the Carbon Negotiator.
Most sustainability tools assume users are willing to do whatever maximizes environmental impact.
Reality is more complicated.
Users optimize for different things:
- Convenience
- Cost
- Time
- Comfort
Instead of insisting on a single recommendation, the system adapts.
Example:
User:
I cannot use public transport.
System:
Alternative Action:
Reduce delivery frequency by 2 orders/week.
Impact:
Medium
Effort:
Low
This creates recommendations that are practical rather than idealistic.
Security Architecture
Because the platform uses AI, all inference occurs server-side.
Browser
│
▼
Server Action
│
▼
Rate Limiter
│
▼
Gemini API
Benefits:
- API keys never reach the client
- Request validation occurs before inference
- Abuse protection through token-bucket limiting
- Reduced attack surface
All incoming payloads are validated through Zod schemas before processing.
The Token Bucket Rate Limiter
One feature that would normally be skipped in a hackathon project was rate limiting.
A token bucket implementation was added to prevent abuse against AI endpoints.
User Request
│
▼
Token Bucket
│
┌────┴────┐
│ Tokens? │
└────┬────┘
│
Yes ▼
Process Request
No
▼
Rate Limited
This became especially important because AI-powered endpoints are often the most expensive resources in an application.
The Recharts Hydration Problem
One of the most difficult bugs involved responsive charts.
The application relied heavily on Recharts.
However:
- The server renders without browser dimensions.
- The client renders with browser dimensions.
This caused hydration mismatches.
The solution involved:
- Deferring chart rendering until mount.
- Creating client-only wrappers.
- Adding explicit minimum dimensions.
- Avoiding SSR-dependent layout calculations.
Without these changes, chart rendering caused layout shifts and degraded performance.
Accessibility First
Accessibility was treated as a product requirement rather than an afterthought.
The application includes:
- Semantic HTML
- ARIA labels
- Keyboard navigation
- Focus management
- Screen-reader-friendly forms
- Accessible dialogs
- Proper radiogroup implementations
This work significantly improved Lighthouse accessibility scores and made the application usable beyond visual interfaces.
Testing Strategy
The project includes:
Unit Tests
Validating:
- Carbon calculations
- ROI scoring
- Recommendation generation
- Validation schemas
End-to-End Tests
Using Playwright to verify:
- User onboarding
- Dashboard rendering
- AI interactions
- Accessibility flows
This resulted in 34 automated tests validating core functionality.
Lessons Learned
The biggest lesson from this build was that AI changes where engineering effort is spent.
AI can accelerate implementation.
It cannot replace architecture.
It cannot replace system design.
It cannot replace quality standards.
The majority of development time was not spent generating code.
It was spent:
- fixing hydration issues
- validating edge cases
- improving accessibility
- strengthening security
- removing warnings
- improving reliability
The difference between a demo and a product is usually found in those details.
Future Directions
Potential next steps for Climbit include:
- Real-time emissions datasets
- Location-aware recommendations
- Carbon budgeting
- Longitudinal footprint tracking
- Community sustainability benchmarks
- AI-powered habit coaching agents
The current version serves as a strong foundation for those future capabilities.
Final Thoughts
Climbit started as a carbon awareness platform.
It evolved into a decision engine.
The most important realization from the project was simple:
People do not need more climate information.
They need better climate decisions.
That shift in perspective shaped every technical and product decision throughout the build.
Top comments (0)