BridgeLend

Inspiration

The inspiration for BridgeLend came from a frustrating personal experience. Watching friends and family get rejected by traditional banks for loans — not because they were bad borrowers, but because the system was designed to exclude them — made me want to build something better. Traditional lending is opaque, slow, and gatekept by institutions that rely on outdated credit scoring models that punish people for not having enough credit history, even when they have steady income and responsible financial habits. At the same time, I kept hearing about people with savings sitting in accounts earning 0.5% interest while inflation eroded their purchasing power. The disconnect was obvious there were people who needed money and people who had money, and there wasn't a good way to connect them directly. Peer-to-peer lending has existed for a while, but platforms like LendingClub felt clunky, opaque, and inaccessible. I wanted to build something that felt modern, transparent, and AI-native — where Ai was woven into every part of the experience. The final push came from thinking about what Claude could actually do inside a financial product. Not just answer questions, but actively analyze borrower profiles, assess risk in plain English, and help both sides of a transaction make better decisions. That felt like something worth building.

What it does

BridgeLend is a peer-to-peer lending platform that connects borrowers with individual lenders. Borrowers connect their bank account, go through a 5-step AI-powered verification process covering identity, income, debt, credit behavior, and risk scoring, and then receive personalized loan offers with real APR calculations. Once they pick an offer, Claude generates a plain-English breakdown of their loan, what it actually costs them, whether it's a good deal, and one tip to save money. On the lender side, users complete a 4-step onboarding flow, set their risk tolerance and lending preferences, and then browse a live table of verified loan requests. They can click into any borrower to see their full financial profile alongside a Claude-generated risk assessment, then fund loans directly. The platform tracks everything — share percentages, funded amounts, lender budgets, and transaction history.

How we built it

We built BridgeLend on Next.js 16 with TypeScript throughout. The database is PostgreSQL on Supabase with five core tables — profiles, lender_profiles, loans, loan_fundings, and transactions — with Row Level Security policies on every table so users can only access their own data at the database layer. A PostgreSQL trigger automatically creates a profile row whenever someone signs up, and another keeps timestamps accurate on every update. Authentication runs through Supabase JWT sessions using the @supabase/ssr library, which handles the difference between browser and server contexts. The backend is a set of Next.js Route Handlers covering auth, loan submission, available loans, funding, and an Anthropic AI proxy that keeps the API key server-side. Monthly payment calculations use the standard amortization formula. The frontend is React with TypeScript and inline styles built around a custom design system using DM Serif Display for headings and DM Sans for body text. The whole thing deploys to Vercel with automatic redeployment on every GitHub push.

Challenges we ran into

The first problem hit immediately — Supabase already has an internal auth.users table, and our schema used public.users which caused an instant naming conflict. We had to redesign the entire schema around public.profiles with a foreign key reference and rewrite all the RLS policies from scratch. The next issue was subtler. Next.js's cookies() function now returns a Promise in newer versions, which broke our server client with a confusing TypeScript error about getAll not existing on a Promise type. A two-line fix once we understood what was happening, but it took a while to diagnose. The most frustrating bug was an environment variable issue where our Supabase URL had /rest/v1/ appended to it, causing an "Invalid path" error on every single API call. It looked completely normal at a glance — we only caught it by running cat -v on the .env.local file which revealed the hidden suffix. On the Vercel deployment, Next.js 16's new behavior of making dynamic route params a Promise broke our build. The params type had to change from a plain object to Promise<{ id: string }> with an await before destructuring. Not documented anywhere obvious. Finally, Supabase's free tier caps email sending at 4 per hour, which we hit almost immediately during testing. We bypassed it by manually confirming users directly in SQL, which was a useful lesson in knowing your way around the database when the normal flow is blocked.

Accomplishments that we're proud of

The thing we're most proud of is how complete the product feels. This isn't a demo with hardcoded data — it's a real application where a borrower can go from signup to a Claude-generated loan analysis in under two minutes, and a lender can browse borrowers, read an AI risk assessment, and fund a loan with everything writing real records to the database. The AI integration feels genuinely useful rather than bolted on, and the design — warm off-white backgrounds, serif headings, animated verification steps — makes it feel like a product someone would actually want to use.

What we learned

Next.js App Router changed how we thought about where data lives and how authentication flows through an application — the line between server and client is much more meaningful than it used to be. We also learned that database-layer security via RLS is fundamentally more robust than application-level auth checks, because even a buggy API route can't leak data if the database itself enforces access rules. And on a more practical note: always verify environment variables with cat -v, because invisible characters and path suffixes are real problems that look like credential errors.

What's next for BridgeLend

The most important next step is real bank integration via Plaid or MX so the verification flow uses actual financial data instead of simulation. After that, ACH payment processing through Stripe or Dwolla would make loan disbursements and repayments real rather than just database entries. Longer term, we want to build a structured AI underwriting engine that outputs a risk grade, recommended interest rate, and maximum loan amount — and a secondary market where lenders can sell positions before maturity to add liquidity to the platform.

Built With

• anthropicclaudeapi
• css
• github
• html
• javascript
• next.js
• node.js
• npm
• supabase
• supabaseauthapi
• supabaserestapi
• turbopack
• typescript
• vercel
• vscode