ecocompass

Inspiration

Every "sustainable material" recommender we looked at does the same trick: it swaps steel for bamboo and calls it a day, without checking whether bamboo can survive the load, the heat, or the certification the original part needed. That gap is why sustainability tools stall out in engineering reviews. A materials engineer doesn't need a tool that suggests green options. They need a tool that tells them which green options are structurally honest, and which ones it's rejecting and why.

We also kept running into the opposite failure mode in consumer apps: eco-scores with no source, no methodology, and no way to tell a verified number from a guess. We wanted to build something that never blurs that line, on either the business side or the consumer side.

What it does

ecocompass is two products sharing one engine.

Analyze BOM (the core, business-facing flow) takes a bill of materials, in whatever format it actually arrives in, and returns:

• A ranked carbon-swap suggestion for every line, scored on carbon, cost, recyclability, and durability
• A rejection panel for any line where no viable swap exists, naming the exact requirement a candidate failed ("tensile strength 30 MPa < required 288 MPa") rather than silently omitting it
• A repairability score built from fastening type, sourcing, service life, and failure risk, with ranked, point-scored fixes ("attach with screws instead of glue: +20 points")
• A blended A–F grade across both carbon and repairability, plus a scaled annual-impact figure once you enter production volume

Scan a product is the free, consumer-facing half: point a phone camera at a barcode or a product, and get a verified eco-score pulled from Open Food Facts and the French repairability index where one exists, or a clearly badged AI estimate where it doesn't. The two are never allowed to look the same on screen.

How we built it

The frontend is React and Vite. The backend is FastAPI and Python. Claude, via the Anthropic SDK, handles every AI task: reading messy BOMs out of photos and scanned PDFs, writing the plain-English briefing that leads with the score and states rejections honestly, pulling real government incentive programs through the web search tool, and estimating repairability when no verified index entry exists.

The part we're proudest of is the carbon-swap engine, because we built it twice on purpose. It exists as a Python module on the backend and a byte-identical JavaScript port on the frontend, down to reimplementing Math.round's rounding behavior so the two never disagree. If the backend goes down mid-demo, the frontend keeps scoring offline and just flips a badge from "via API" to "offline engine." For a 24-hour build, that redundancy bought us a lot of peace of mind.

BOM ingestion got more attention than we originally planned, because real BOMs are ugly. We wrote a CSV parser that handles quoted fields, embedded commas, and stray encoding issues without a single dependency, plus header-alias detection so a column named qty_kg or desc still maps correctly. When a material can't be matched, we run it through synonym tables and then a category proxy (steel for "metal", ABS for "plastic") rather than dropping the row. When a mass is missing, Claude estimates it and flags the estimate. Nothing in the BOM gets silently thrown away.

Repairability scoring runs off a transparent, auditable rule set in a JSON file rather than a hidden model call: fastening type alone swings a score by up to 27 points, from sealed/potted (-15) to screwed (+8). Every point is traceable back to one row in one table.

Challenges we ran into

Getting the two carbon engines to actually agree took longer than writing either one individually. JavaScript and Python round differently at the boundary cases, and a single rounding mismatch between the offline and online paths would have undermined the entire "you can trust this number" pitch. We ended up writing a custom rounding function in the Python port just to match JavaScript's behavior line for line.

The barcode scanner was its own fight. BarcodeDetector only exists on Chromium browsers, so iOS Safari and Firefox needed a fallback that captures a still frame and routes it through Claude's vision instead. We also had to require two consecutive matching reads before accepting a scan, because a single frame kept misfiring on similar-looking barcodes.

The honest one: we ran out of time to drop the actual French repairability index CSVs into the data folder. The parser, the schema, and the tests for it are all built and passing against fixtures, so wiring in the real data is a matter of hours, not a redesign. Until then, scan mode falls back to the AI-estimated path for repairability, and we say so in the product rather than pretending otherwise.

Accomplishments we're proud of

Building a recommender that says no. Most tools in this space are afraid to reject anything, because a rejection looks like a failure. We made the rejection the trust feature: showing the most tempting low-carbon material a part can't use, and exactly why, does more for credibility than any number of green checkmarks.

We're also proud that every AI call degrades to a clean error instead of a crash, and that the deterministic scoring never depends on Claude being reachable at all.

What we learned

Sustainability tooling earns trust through the things it refuses to do, not the things it recommends. A rejected swap with a clear reason is worth more to a materials engineer than ten green suggestions with no constraint checking behind them. We also relearned a basic lesson about hackathons: build the boring, ugly parsing logic first. The CSV edge cases and header-alias mapping ate more of our 24 hours than the AI integration did, and none of the AI features would have mattered if a real-world BOM couldn't get into the system in the first place.

What's next

Loading the real French repairability index data is the immediate priority, since it's the one claim on the scan page that isn't fully backed yet. After that: replacing the placeholder carbon-intensity bands with sourced USEEIO or Agribalyse figures, wiring the "suggest a material" form to an actual submission pipeline, and adding lightweight moderation to community-contributed product data before it goes live.

Built With

• 67
• ai
• b2bsaas
• claude
• javascript
• python
• react