The problem LeakLens solves

When your email shows up in a data leak, the existing tools tell you almost nothing useful. You get a list of company names and dates, no sense of how serious it actually is, no explanation of what was exposed, and no clear next step. Most people either panic over something minor or ignore something that actually matters.

There's also a trust problem most people don't think about: checking whether your own account was compromised means handing your email to whichever company runs the lookup, and trusting that they're not logging it themselves.

LeakLens solves both problems.

• Checks an email against known data leaks
• Runs the result through multiple independent AI models on Gonka Router, each one scores severity and explains in plain language what was actually exposed
• If the models disagree on how serious something is, that disagreement is shown rather than hidden, so you know when a verdict needs a second look
• Every inference step is backed by a visible Gonka Request ID, so the assessment can't be traced back to a centralised operator quietly logging your data

The result is a clear leak score, a plain-language explanation of what's actually at risk, and a prioritised checklist of what to secure first, instead of a bare list you have to interpret yourself.

Challenges we ran into

1. AI Rate-Limiting & Token Exhaustion

While testing our multi-model consensus logic against the Gonka Router and XposedOrNot APIs, we quickly hit 429 Too Many Requests errors. Spam-clicking the "Scan" button during UI testing was burning through our Gonka test network tokens and locking us out of the leak database.

• How we got over it: We implemented a strict client-side session cache (SESSION_CACHE) in our vanilla JavaScript frontend using Maps. If a user scans an email they've already checked during that session, the dashboard instantly serves the cached JSON payload instead of re-pinging the network. We paired this with strict UI debouncing, disabling the submit button and rendering a loading spinner while the dual-layer API pipeline resolves.

2. Decoupling the UI from Pending AI Logic

Because we are a team of four, we couldn't afford to have the frontend developer sitting idle while the backend team engineered the Gonka API integration and cross-model prompt logic.

• How we got over it: We defined a strict JSON data contract on day one. We built the entire frontend using a hardcoded MOCK_AI_VERDICT object that mirrored the exact shape the Gonka Router would eventually return. We also engineered "graceful degradation" into the UI: if the AI consensus layer fails or the Gonka key isn't configured (returning a 503), the dashboard doesn't crash. Instead, it gracefully displays an amber "Unavailable" badge for the AI score while still successfully rendering the underlying XposedOrNot breach data.

3. Late-Stage Git Merge Conflicts

Working in a lightweight, zero-build-step environment (pure HTML/CSS/JS) meant multiple team members were frequently touching the same app.js and style.css files. Near the end of the build, pulling the backend API routes into the frontend branch resulted in a massive merge conflict that threatened to wipe out hours of UI styling.

• How we got over it: Rather than risking a broken file state by manually untangling Git conflict markers under a deadline, we executed a "clean clone" strategy. We cloned a fresh instance of the remote repository (LeakLens-Clean), manually injected our finalized UI files, and pushed the clean commit. We then had the whole team pull from main, resetting everyone to a unified, functional state.