LoanShield

Inspiration

Students often face high-pressure, low-friction lending pages with hidden fees and misleading APR wording. Schools need a way to support students early without turning browsing into surveillance. LoanShield was inspired by combining local, explainable checks, cooling-off reflection, and optional school visibility when students consent.

What it does

LoanShield helps students pause before borrowing: a browser extension detects lending-like pages and form behavior, walks users through reflection questions and risk context (including cashflow-style APR reasoning), and can send anonymized risk events to a school backend. A school console shows aggregates and events; a student web UI handles consent and safety workflows on the same API.

How we built it

We used a Manifest V3 extension (content scripts + a service worker for reliable API posts), a Node/Express backend with REST APIs for risk events, consent, and support content, and static frontends for the student app and school console. We deploy the stack on Render and host demos on GitHub Pages, with CORS-aware configuration and shared API keys where needed.

Challenges we ran into

1,Making automatic detection reliable across real pages (iframes, partial data, and session limits so users aren’t spammed). 2,Cross-origin issues: moving risk POSTs to the extension background so GitHub Pages and HTTPS sites don’t silently fail. 3,Helping users configure one correct backend URL across the extension, school console, and hosted static sites (vs. localhost). 4,Explaining effective cost when marketing APR and fees don’t match real cashflows.

Accomplishments that we're proud of

1,A full loop: extension → backend → school dashboard, demo-ready on a public URL. 2,A structured cooling-off flow aligned with a real support narrative, not just a single alert. 3,Practical deployment (Render + Pages) so judges can open links instead of only reading slides.

What we learned

1,UX and trust matter as much as formulas: users need clear why and what happens next. 2,Browser security (CORS, MV3) is a first-class part of “it works on my machine.” 3,Schools and students need defaults that are privacy-conscious and explicitly opt-in for sharing.

What's next for LoanShield

1,Deeper scenario parsing and clearer IRR / fee explanations across messy real-world copy. 2,Stronger consent UX and auditability for school-facing views. 3,Pilot feedback from student affairs or financial literacy partners, and optional integrations with campus resources (work-study, aid) where APIs exist.

Built With

• cursor
• vibecoding