EcoSwipe

Inspiration

Booking a home service today usually means scrolling a wall of near-identical listings with vague "verified" badges and no real way to know if "eco-friendly" means anything or is just marketing. At the same time, most sustainability apps make going green feel like homework guilt-trippy dashboards nobody opens twice. We wanted the opposite: a booking experience people would actually enjoy using, where the sustainable choice is also the fastest, most obvious one and where "trust score" and "carbon saved" are actually computed from real behavior, not just decorative numbers.

What it does

EcoSwipe is a full-stack home services marketplace built around a Tinder-style swipe deck: every card shows a service's real price, ETA, and carbon savings versus a modeled traditional-service baseline. Behind that deck sits a Bayesian trust-scoring engine that rates providers on actual completion rate, punctuality, and repeat-hire behavior instead of inflated star averages. Users can also just describe what they need in plain English "eco plumber under ₹500 tomorrow morning" to a Claude-powered booking agent that extracts intent, matches real providers, remembers context across a conversation ("book the first one"), and falls back to regex parsing if the LLM is unreachable. Sustainability is gamified through EcoFix, a daily eco-decision mini-game with per-scenario difficulty that unlocks real discount coupons capped to one per person per week. An admin console handles booking approval, a swipe-to-booking conversion funnel, and demand heatmaps, and every booking generates a downloadable impact receipt breaking down carbon, money, and time saved.

How we built it

The backend is Node.js/Express with SQLite (via better-sqlite3) as the primary store, optionally recalibrated from Supabase-hosted benchmark data. Auth is JWT-in-httpOnly-cookie with CSRF token verification and role-based access (dev-mode auto-grants admin locally). The frontend is intentionally vanilla JS/HTML/CSS no bundler except for the EcoFix game, which loads React 18 and Babel Standalone from CDN and JSX-transpiles in the browser at runtime, so it ships without a build step. The Claude API integration uses raw fetch calls against the Messages API with a structured-extraction system prompt, backed by a regex fallback path so the assistant degrades gracefully instead of breaking. Provider trust scores use a Bayesian-smoothed reliability estimate (prior-weighted toward the population mean for providers with few completed jobs) rather than a naive average, specifically so a provider's first booking can't swing their score wildly.

Challenges we ran into

The hardest bugs weren't the ones we expected. EcoFix originally used one flat score threshold (60) to unlock coupons for every daily scenario but when we actually computed the true achievable ceiling for each day's fix combinations, two days' content couldn't mathematically reach even a modest floor we'd set, which would have made those days permanently unwinnable. We had to brute-force each day's real scoring ceiling from the actual game data and derive per-day targets as a percentage of that ceiling instead of guessing a number. Separately, we found and closed a real coupon-eligibility loophole where a secondary "general engagement" scoring path let users unlock EcoFix rewards without ever playing the game. And a chart-styling pass revealed that our gradient-animation code was hardcoding the theme's teal accent as the glow color for every bar regardless of the bar's actual color, which read as a jarring clash on anything not teal.

Accomplishments that we're proud of

Running our own calibration model against the real 20-service catalog gives an honest 74.5% average carbon reduction and 29.6% average time savings versus the traditional-service baseline numbers we computed by actually executing the app's logic, not projecting them. We're proud that the trust-scoring system reports its own confidence band (so a provider with 2 jobs is visibly less certain than one with 20) instead of pretending every score is equally reliable. And we're proud of catching and fixing our own security/fairness bugs the coupon loophole and the unwinnable-day bug before they shipped, by actually testing against real data rather than trusting the code by inspection.

What we learned

The biggest lesson was to distrust our own assumptions the moment real data was available to check them against. The flat-60 threshold and the engagement-based coupon path both looked reasonable in isolation and only broke down once we simulated real play patterns. We also learned that "vanilla JS with no build step" and "ship a real React feature" aren't mutually exclusive CDN + runtime Babel transpilation let one page (EcoFix) use React 18 without forcing a bundler onto the rest of the app. And building the Claude-powered agent taught us that a good fallback path matters as much as the AI integration itself; ours needed to work coherently even with zero API credits.

What's next for EcoSwipe

Near-term: give the booking agent access to real-time provider availability so it can propose exact slots instead of just matching categories, and extend its conversation memory to handle multi-step booking flows end-to-end. Medium-term: move providers off the hardcoded service catalogue into a fully dynamic, provider-managed listing system, and build a provider-facing app so businesses can manage their own bookings instead of going through admin approval. Longer-term: pilot with a real local provider network to see whether our modelled carbon/time savings hold up against actual measured outcomes, not just our calibration model.