Forem: Damola Adegbite

I built a tool that shows developers what their backend costs the planet

Damola Adegbite — Sat, 18 Apr 2026 19:44:55 +0000

I built a tool that shows developers what their backend costs the planet

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

carbondebt is a cloud emissions dashboard for backend developers. Put in your cloud provider, region, and monthly compute hours. It calculates your CO2e footprint, breaks it down by service, and uses Google Gemini to return ranked actions with estimated carbon savings per month.

No account. No setup. Results in under ten seconds.

Developers track technical debt across quarters. We argue about it in code review, carry it into sprints. But there is another kind of debt building up in every infrastructure decision, one that never shows up in your AWS bill. Carbon debt works the same way. It compounds quietly and stays invisible until someone surfaces it. This tool surfaces it.

Demo

Live: carbondebt-client.vercel.app

Open the app, select AWS, set the region to us-east-1, leave compute hours at 720. Then switch to eu-north-1. Stockholm's grid is 76% cleaner than Virginia's. That difference is a decision most developers have never been asked to make.

Code

dax-side / carbondebt

carbondebt

carbondebt is a cloud emissions dashboard for developers Enter your workload numbers, then get a monthly footprint estimate and a ranked action list.

Live demo: carbondebt-client.vercel.app

What you get

Total monthly CO2e
Grid intensity for the selected region
Emissions split by service (compute, database, storage, network, lambda)
Best lower-carbon region inside the same cloud provider
Gemini suggestions sorted by estimated monthly savings

How carbon is calculated

The backend uses scope 2 location-based emissions from local region intensity data. Intensity values come from Ember Global Electricity Review 2025.

Formula:

CO2e (kg) = kWh * grid_intensity (gCO2e/kWh) / 1000

Source file for region values: server/src/data/regions.ts

Stack

Frontend: React, Vite, TypeScript, Tailwind CSS
Backend: Node.js, Express, TypeScript
Validation: Zod
AI: Google Gemini
Logging: Morgan + Winston

API

GET /api/health

Returns service status.

POST /api/carbon

Request body:

{
  "provider": "aws"
  "region": "us-east-1",
  "computeHours": 720

…

View on GitHub

How I Built It

The frontend is React with TypeScript and Tailwind. The backend is Node.js and Express. No database. Every request is self-contained.

Carbon calculations run locally on the server using regional grid intensity data from the Ember Global Electricity Review 2025 dataset. No third-party emissions API. The numbers are transparent and traceable to the source.

One thing I added that changed how the data reads: the "equivalent to X km driven" metric. Saying a workload produces 125 kg CO2e per month is accurate but abstract. Converting it to kilometres driven makes the number land for people who have never thought about this before.

Gemini integration: After the carbon report is calculated, it goes to Gemini which returns 3 to 5 ranked infrastructure suggestions specific to the submitted workload. Not generic advice. Things like "switch to Graviton3 instances" or "stop non-production servers outside business hours" with an estimated kg saving attached to each one. The formula gives you the number. Gemini tells you what to do with it.

Prize Categories

Best Use of Google Gemini

Gemini takes the carbon report and turns it into something a developer can act on today. Each suggestion is ranked by estimated monthly CO2e saving and tied to the actual workload submitted. If Gemini is unavailable, the carbon report still renders. The suggestions are an addition, not a dependency.

GitNotion — GitHub to Notion sync with AI reports

Damola Adegbite — Mon, 16 Mar 2026 11:09:57 +0000

This is a submission for the Notion MCP Challenge

What I Built

GitNotion is an MCP server that pulls GitHub activity into Notion and uses Gemini to write reports on top of it. Point it at any repo and it syncs issues, PRs, and commits into structured Notion databases, then generates weekly summaries, release notes, and contributor breakdowns. All free APIs, ships via npx.

Eight MCP tools, accessible from Claude Desktop, Copilot, or any MCP client:

Tool	What it does
`setup_workspace`	Creates 4 Notion databases under a parent page
`sync_issues`	Pulls GitHub issues into Notion
`sync_pull_requests`	Pulls PRs into Notion
`sync_commits`	Logs recent commits to Notion
`generate_summary`	Sends last week of activity to Gemini, writes a summary page
`generate_release_notes`	Generates release notes from merged PRs and commits
`get_contributor_insights`	Per-contributor stats with an AI written report
`full_sync`	Runs everything above in sequence

Re-running any sync tool updates existing entries. No duplicates.

Video Demo

Show us the code

Repo: https://github.com/dax-side/gitnotion

npm: npx -y gitnotion

How I Used Notion MCP

GitNotion embeds the official @notionhq/notion-mcp-server as a dependency and uses it as the write layer for all page operations. The architecture:

AI Agent (Claude, Copilot, etc.)
    ↓ MCP protocol
GitNotion MCP Server  ← custom server
    ├── GitHub API (read repo data)
    ├── Gemini API (generate reports)
    └── Official Notion MCP Server  ← all page/block writes go here
         └── Notion API

When a sync or AI tool runs, GitNotion spawns the official Notion MCP server as a subprocess, connects to it as an MCP client, and routes all page create, update, and block append calls through it using API-post-page, API-patch-page, and API-patch-block-children. Database creation goes through the Notion SDK directly since the official server doesn't expose that endpoint.

Gemini returns markdown. Notion doesn't accept markdown — it wants structured block objects for every heading, list item, table row, and inline annotation. The converter handles all of that, then the blocks get sent to the official MCP server via API-patch-block-children in chunks of 100. Chunking is needed because passing large content in a single call times out. The pattern is: create the page first with no children, then append in batches.

To use it, add this to your MCP client config:

{
  "mcpServers": {
    "gitnotion": {
      "command": "npx",
      "args": ["-y", "gitnotion"],
      "env": {
        "GITHUB_TOKEN": "...",
        "GITHUB_REPO": "owner/repo",
        "NOTION_TOKEN": "...",
        "NOTION_PARENT_PAGE_ID": "...",
        "GEMINI_API_KEY": "..."
      }
    }
  }
}

Four free things needed: GitHub token, Notion integration token (connected to your page via ••• > Connections), Gemini API key, and the Notion parent page ID from the URL. Ask your MCP client to run setup_workspace, then pass the returned database IDs to full_sync.