Inspiration
AI data centers consume massive amounts of electricity, and nearly all of it ends up as waste heat vented into the air and lost. At the same time, villages and small towns near these facilities often struggle with unreliable electricity and expensive heating. We started by asking whether a data center's noise could power a village. The physics said no, but it pointed us toward the real resource: the heat. That question became OORJA AI — a bridge between the energy AI wastes and the communities that could use it. ("Oorja" means "energy" in Hindi.)
What it does
OORJA AI lets you search for an AI data center and view its profile. It estimates the monthly recoverable energy, mostly usable heat plus a small optional amount of electricity, shown as Low, Base, and High ranges rather than one falsely precise number. It then maps nearby villages and towns, ranks them with a transparent match score, and suggests uses like greenhouse heating or crop drying. An Explore Map shows every data center in the dataset, color-coded by cooling type, and each detail page also shows distances to every other data center. Finally, an impact panel shows households served and COâ‚‚ avoided. We never claim a data center "produces" electricity, and every number carries a badge: Reported, Estimated, or Dummy.
How we built it
We used React, Vite, TypeScript, and Tailwind CSS, with Leaflet and OpenStreetMap for all three maps (home preview, Explore Map, and detail-page maps) and Recharts for the energy breakdown charts. Data comes from the Overpass API for nearby villages and farmland, Nominatim for geocoding, Open-Meteo for temperature data, and NASA POWER for solar irradiance. A tested calculation engine (energy.ts) models heat capture by cooling type, and a separate community-matching engine (communities.ts) scores and ranks nearby places by distance, demand, and need. We deployed the final app on Netlify. ruby
Simplified core of the energy calculation
consumed_mwh = capacity_mw * utilization * hours recoverable_heat = consumed_mwh * capture_fraction
Challenges we ran into
Our original idea, turning data center noise into electricity, didn't survive the math: acoustic harvesting yields microwatts against a demand of megawatts, a gap of about ten orders of magnitude. Pivoting to waste heat meant rethinking the whole project. Public data on data center capacity and cooling is also patchy, so we leaned on ranges and data-quality badges instead of false precision. Heat doesn't travel far, so our matching logic had to treat heat and electricity differently, with separate distance-decay curves. We also hit real build friction: running low on AI coding credits mid-hackathon forced us to merge code from multiple tools by hand rather than relying on one agent end to end.
Accomplishments that we're proud of
We turned a flawed first idea into a scientifically defensible one, grounded in real thermodynamics rather than a catchy gimmick. Our match score is fully transparent, visible on hover, with no black-box ranking. Every number on the site shows a range and a data-quality label. And the full flow works end to end: search a data center, see its energy estimate, explore the community map, and check it against every other site in our dataset.
What we learned
Quick physics checks early save enormous time; a five-minute order-of-magnitude calculation told us our original sound-to-electricity idea was a dead end before we wrote a line of code. Honesty about uncertainty makes a project more credible, not less — showing a range built more trust with the people we tested it on than a single confident-looking number would have. Open data sources like OpenStreetMap, NASA, and Open-Meteo can power a surprisingly capable tool without any paid API keys. And we learned to combine AI coding tools pragmatically: splitting work across a few free tiers, and being ready to merge and debug manually when one runs out of credits mid-build.
What's next for OORJA AI
We'd like to bring in real operator data through partnerships, add heat-pipeline cost and payback modeling to turn a match into an actionable business case, include water-use and water-stress impact alongside the energy picture, and offer siting guidance so new data centers can be planned near existing heat demand from the start. We'd also like to finish the Hindi-language toggle we scoped but didn't have time to build, and add one-click municipal reports that a local government could hand directly to a data center operator to start a real conversation.
Built With
- claude
- google-antigravity
- leaflet.js
- nasa-power-api
- netlify
- nominatim-api
- open-meteo-api
- openstreetmap
- overpass-api
- react
- react-router
- recharts
- tailwindcss
- typescript
- v0
- vite
- windsurf
Log in or sign up for Devpost to join the conversation.