DEV Community

Mithunvisvesh S
Mithunvisvesh S

Posted on

How I Built CarbonCompass with Google Antigravity — A Personal Sustainability Coach, Not Just a Calculator

Most carbon footprint apps do the same thing:

Quiz → "Your footprint is 120 kg CO₂/week" → Generic tips → User never returns.

That's not a coaching experience. That's a guilt trip with no follow-through.
For PromptWars Virtual — Challenge 3 (Carbon Footprint Awareness & Reduction), I built CarbonCompass with a different premise:
Not just measure. Guide.
Live demo: https://prompt-wars-virtual-hackathon.vercel.app/

The Problem with Existing Carbon Tools
I started by looking at what already exists — Capture, Klima, JouleBug. Each of them calculates a footprint accurately. But they all fail at the same step: the recommendation layer.
"Install solar panels." "Buy an EV." "Go vegan."
These are structurally correct but useless for a hostel student in Chennai who travels by bus and eats at the mess. They're recommendations designed for a demographic that already has money and flexibility.
CarbonCompass is built around two real Indian users:

Aditi — a college student in Chennai. Bus commute, hostel mess food, shared room electricity. Her biggest carbon lever is food waste, not transport.
Rohan — a tech professional in Bengaluru. Petrol car + scooter commute, air-conditioned 2BHK, frequent food delivery. His biggest lever is home energy, not diet.

The same app, two users with different lifestyles receive coaching tailored to their highest-impact opportunities. That's the core product promise.

The Architectural Decision That Made Everything Work
Before writing a single line of code, I ran this prompt in Google Antigravity's Plan Mode:
You are a senior product architect.

Before coding:

  1. Generate user personas
  2. Design a SINGLE shared calculation module that the Dashboard, Impact Simulator, and AI Coach all call with the same inputs
  3. Create the data schema
  4. Propose page architecture
  5. Flag risks for a one-week build

Do not write code yet. Create an Implementation Plan.
The agent produced a full Implementation Plan artifact — a structured document I could review and annotate before any code was generated. This step saved at least a day of rework.
The plan's most important output was the shared calculation engine — a single file (carbonCalculator.js) with one function, sourced emission factors, and one contract:
js// All emission factors in one place. Sourced. Commented.
export const EMISSION_FACTORS = {
electricity: 0.75, // CEA CO2 Baseline Database, India
lpg_cylinder: 42.0, // Indian household LPG data
transport: {
petrolCar: 150, // g CO2/km — CarbonCrux India fleet mix
bus: 89, // g CO2/passenger-km — Defra proxy
cycling: 33.0, // Our World in Data
// ...
},
diet: {
high_meat: 7.19, // kg CO2e/day — Scarborough et al. 2014
vegetarian: 3.81,
vegan: 2.89,
},
foodWaste: 2.5, // kg CO2 per kg wasted — Poore & Nemecek 2018
};

export function calculateWeeklyFootprint(inputs) {
// One function. Called by Dashboard, Simulator, and AI Coach.
// ...
}
The formula:
weekly_footprint = transport + energy + diet + waste

transport = Σ(km/week × g CO2/km) ÷ 1000
energy = (kWh/week × 0.75) + (LPG cylinders/month ÷ 4.33 × 42)
diet = daily_kg_CO2e[diet_type] × 7
waste = food_wasted_kg/week × 2.5
I wrote a verification script (verifyCalculator.js) that checked both personas against hand-calculated expected values. It passed at 100% match. This gave me confidence that the numbers the user sees are real, not made up.
Why this matters: Any team that writes separate logic for the dashboard, the simulator, and the AI layer will eventually produce contradictory numbers. "Your footprint is 120 kg" on the dashboard, "estimated 108 kg" in the simulator, and "your biggest category is transport" from the AI — when transport isn't actually the biggest. I've seen this fail in demos. The shared engine prevents it entirely.

How I Used Google Antigravity
I used Plan Mode for every structural task (new pages, new features). The workflow was:

Write a prompt describing the goal, the stack, and the design tone
Let the agent produce an Implementation Plan artifact — a structured list of what it planned to build and verify
Read it, annotate it with comments if something looked wrong
Only then approve it and let the agent write code
The agent opened a real browser, clicked through the flow, took screenshots, and attached them to a final Walkthrough artifact

For smaller fixes (changing a label, adjusting a color), I used Fast Mode — just execute, no plan needed.
The most valuable moment was when the dashboard, simulator, and AI coach were each being built. I explicitly included this in every prompt:
IMPORTANT: Do not write a new calculation function.
Import calculateWeeklyFootprint from ../utils/carbonCalculator.js
and call it with these inputs. Never duplicate the formula.
The agent generally respected this constraint, and I manually reviewed all generated code to ensure the shared calculation engine remained the single source of truth. Having it written in the Implementation Plan artifact — which I'd reviewed and approved — meant there was a shared understanding between me and the agent about the architecture before any code existed.

The AI Layer — Interpretation, Not Calculation
The AI Habit Coach uses Gemini 2.0 Flash via a secure serverless proxy (api/gemini.js on Vercel). The API key never touches the client bundle.
The core design principle: AI interprets user data. AI never calculates footprint.
Here's the relevant part of the system prompt:
You are CarbonCompass's AI Habit Coach.
You have been given the user's ALREADY CALCULATED weekly carbon
footprint breakdown by category.

CRITICAL RULES:

  • DO NOT perform any carbon calculations.
  • DO NOT suggest the user buy expensive equipment.
  • ONLY suggest actions that take under 10 minutes and cost under ₹500/month.
  • Generate exactly 3 challenges as valid JSON. Every challenge recommendation is constrained to "Small Wins" — under 10 minutes, under ₹500 — baked into the prompt itself, not just into the UI copy. The app includes a graceful fallback (curated static challenges) if the API call fails or times out.

The Impact Simulator
The simulator is the moment that makes people lean forward in a demo.
A slider. Real-time update. "What if I cycled to college twice a week?" → watch the projected footprint drop from 117 kg to 108 kg, with a -8% badge and "equivalent to 19 trees planted" context card.
It's deterministic — no AI, no API call, no chance of failure. It calls the same calculateWeeklyFootprint() function with modified inputs and renders the delta instantly.

Methodology and Data Honesty
The app has a dedicated Methodology & Sources page that lists every emission factor, its source, and a honest disclaimer:

Dietary data is UK-based (Scarborough et al. 2014) and serves as a comparative proxy for urban Indian dietary habits. It is not exact.

Hackathon judges are technical people. They will ask "where do these numbers come from?" Having a sourced, transparent methodology page that proactively acknowledges data limitations builds more credibility than overclaiming precision.

What I'd Build Next

Replace localStorage with a real backend (Supabase) so progress persists across devices
A shareable "My Carbon Card" — one-click export of the dashboard headline to LinkedIn or WhatsApp
India-specific dietary lifecycle data to replace the UK proxy
A real behavior-change verification layer (photo proof or location check-in for challenges completed)

Try It
Live app: https://prompt-wars-virtual-hackathon.vercel.app
Use the "Load Aditi" or "Load Rohan" quick-fill buttons on onboarding to explore both personas in under 30 seconds.
Built with Google Antigravity · Gemini 2.0 Flash · React 19 · Tailwind CSS · Vite · Vercel
PromptWars Virtual — Challenge 3: Carbon Footprint Awareness & Reduction

Top comments (0)