DEV Community: Divyanshu Sinha

# Building Climbit: An AI Climate Decision Engine in Under 12 Hours

Divyanshu Sinha — Mon, 22 Jun 2026 04:37:24 +0000

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.

Building NotesGPT: An Offline-Capable AI Study Assistant with RAG, Local LLMs, and WebGPU

Divyanshu Sinha — Wed, 10 Jun 2026 03:27:25 +0000

We all know the feeling.

Exams are approaching, notes are scattered across PDFs, handwritten notebooks, lecture slides, and screenshots, and tools like ChatGPT, Gemini, and NotebookLM suddenly become indispensable.

I was using these tools extensively during my own exam preparation when a different question started bothering me:

How are these systems actually built?

Not from a user's perspective.

From an engineer's perspective.

How does an uploaded PDF become searchable?

How does an AI know which paragraph from a 200-page textbook contains the answer?

How does NotebookLM generate responses grounded in your notes instead of hallucinating information?

And perhaps the most practical question:

Could I build something similar that continues working when the internet doesn't?

Living in a PG with unreliable Wi-Fi made that challenge particularly interesting.

That curiosity eventually became NotesGPT.

A hybrid cloud and local AI study companion capable of processing PDFs and handwritten notes, generating revision material, creating flashcards and mock exams, and answering questions using Retrieval-Augmented Generation (RAG).

The Problem

Most AI-powered study tools today are heavily dependent on cloud infrastructure.

The moment your internet becomes unstable:

Uploads fail
Responses slow down
Features become unusable
Productivity drops

For students, this often happens at the worst possible moment.

I wanted to explore a different approach:

Instead of choosing between cloud and local AI, why not support both?

Project Goals

The project had four major goals:

1. Document Understanding

Accept:

PDFs
Lecture notes
Handwritten notes
Scanned textbooks

and convert them into searchable knowledge.

2. Context-Grounded Answers

Prevent generic LLM responses.
Answers should come from the uploaded material itself.

3. Offline Capability

Allow the system to continue functioning without cloud access.

4. Multiple Study Outputs

Generate:

Revision notes
Flashcards
Question banks
Mock examinations
Interactive Q&A

from the same knowledge source.

High-Level Architecture

Documents
      │
      ▼
Text Extraction
(PDF.js / OCR)
      │
      ▼
Chunking
      │
      ▼
Embeddings
      │
      ▼
Vector Storage
      │
      ▼
Similarity Search
      │
      ▼
Retrieved Context
      │
      ▼
LLM Generation
      │
      ▼
Notes / Flashcards / Chat / Exams

The architecture follows a classic Retrieval-Augmented Generation pipeline, but with support for both cloud and local execution.

Why RAG Instead of Just Sending the PDF to an LLM?

One common beginner approach is:

Upload PDF
↓
Send PDF to LLM
↓
Get Response

This works for small documents.

It breaks down quickly when:

Documents become large
Token costs increase
Context windows are exceeded
Retrieval quality degrades

Instead, NotesGPT uses Retrieval-Augmented Generation.

The workflow:

Extract text
Split into chunks
Generate embeddings
Store embeddings
Retrieve relevant chunks
Generate answers using retrieved context

This provides:

Lower token usage
Better accuracy
Faster responses
Grounded answers
Source traceability

Building the Offline Layer

This became the most interesting part of the project.

Most AI applications support a single inference engine.

I wanted flexibility.

NotesGPT currently supports three different local execution modes.

Ollama

For users with stronger hardware.

Benefits:

Full local privacy
Better model quality
No cloud dependency

Example models:

deepseek-r1:8b
gemma2:2b

WebLLM

This was fascinating.

WebLLM allows LLMs to run entirely inside the browser using WebGPU.

No external application.
No backend.
No cloud calls.

Just:

Browser
+
WebGPU
+
Local Model
=
Offline AI

This makes deployment dramatically simpler.

Gemini Nano (window.ai)

Modern browsers are slowly introducing built-in AI capabilities.
Supporting Gemini Nano was an experiment in understanding what local browser-native AI could look like in the future.

OCR Pipeline

Students don't only upload PDFs.

They upload:

Notebook photos
Whiteboard images
Scanned assignments

Supporting these required OCR.

I implemented two OCR paths.

Local OCR

Using:

Tesseract.js

Benefits:

Privacy
Offline support
Zero API cost

Tradeoff:

Lower accuracy

Cloud OCR

Using:

Gemini Vision

Benefits:

Higher accuracy
Better handwriting recognition

Tradeoff:

Requires internet

This dual-mode approach gave users flexibility depending on their situation.

One Optimization That Reduced Latency by 70%

The original study-kit generation pipeline looked something like this:

Generate Notes
     ↓
Wait
     ↓
Generate Flashcards
     ↓
Wait
     ↓
Generate Questions
     ↓
Wait
     ↓
Generate Mock Exam

This required multiple LLM calls.

Consequences:

Slow generation
Increased token usage
Higher failure probability
API rate limits

I redesigned the workflow into a single structured generation request.

Results:

Metric	Before	After
Generation Time	~60 sec	<15 sec
API Calls	4+	1
Token Usage	High	Reduced
User Experience	Slow	Fast

The lesson:

System architecture often matters more than model selection.

Optimizing Vector Search

Another challenge appeared during retrieval.

The naive approach:

Fetch everything
Compute similarity
Return results

This quickly becomes inefficient.

Instead:

Fetch embeddings and metadata
Compute similarity in memory
Retrieve only top-ranked chunks

Benefits:

Lower bandwidth usage
Faster retrieval
Reduced database reads
Better scalability

Tech Stack

Frontend

Next.js 16
React 19
Tailwind CSS 4
Framer Motion

AI

Gemini 2.0 Flash
Ollama
WebLLM
Gemini Nano

Storage

Firestore Vector Collections
IndexedDB
TF-IDF Local Search

OCR

Tesseract.js
Gemini Vision

Authentication

Firebase Authentication

What I Learned

Before building this project, I assumed AI applications were mostly about prompts and models.

After building it, I realized the opposite.

The hardest parts were:

Retrieval quality
Latency optimization
Storage architecture
Offline execution
OCR reliability
Error handling
Cost efficiency

The LLM itself was only one component.

Everything around the model turned out to be equally important.

Future Improvements

A few areas I would like to explore next:

Hybrid vector search
Incremental indexing
Better citation grounding
Multi-document reasoning
Voice-based study sessions
Mobile-first offline deployment
On-device embedding generation

Final Thoughts

I originally started this project because I was curious about how tools like NotebookLM worked behind the scenes.

What began as an experiment eventually became one of the most educational engineering projects I've built.

It taught me far more about AI systems, retrieval pipelines, optimization, and software architecture than simply consuming AI tools ever could.

If you're interested in AI engineering, RAG systems, local LLMs, or offline-first applications, I'd love to hear your thoughts.

GitHub Repository: https://github.com/di0206-innovator/Notes-GPT