BookBridge

An urban-infrastructure and connectivity solution: matching disadvantaged-students with old books

Comment

Inspiration

A teacher we talked to described the problem in two sentences: half her students owned more workbooks than they'd ever read, and the other half were photocopying chapters because they couldn't afford the textbook. Both groups were five minutes apart in the same building. Library donation bins exist, but they don't match anything — they just collect books and hope. We wanted a system that matches by subject and grade level instead of "donate stuff and see what happens."

The harder problem showed up once we sketched the request side. Every version of "verify need" we drew ended the same way: asking a child to prove they couldn't afford a book. That's the part we kept rejecting. So the question we actually built around wasn't "how do we verify poverty" — it was "who already knows this kid needs help, and can we just ask them instead." That's BookBridge.

What it does

BookBridge runs on three pieces:

  1. Listing and matching — Donors post a book with subject, level, condition, and a photo. Requesters search by the same two fields — subject and level — and nothing else, because that's the only filter that actually matters for finding a usable book fast.
  2. Verification via a trusted adult — A teacher, counselor, or partner nonprofit issues a short code to a student who needs help. The student enters the code at request time. No income forms, no proof of anything from the kid — the adult who already knows the situation vouches for it.
  3. Status pipeline — Every book moves through available → requested → claimed, so both sides always know where things stand instead of wondering if a request went anywhere.

That's the whole feature set. No messaging, no ratings, no feed — on purpose.

How we built it

Frontend is React with Tailwind. Backend logic runs on Node.js, with Firebase handling auth and storage across four collections: books, users, requests, and verification codes. Subject/level filtering is a plain query against two indexed fields — we skipped a search engine because the data and query pattern don't need one.

The one piece we deliberately faked was verification onboarding. Instead of building real intermediary accounts (school logins, nonprofit dashboards, code-issuing flows), we hardcoded a small set of valid codes server-side. That kept build time on the part that actually gets exercised in a demo — listing → request → claim — instead of an account system nobody would click through in five minutes.

Challenges we ran into

Killing our first verification design. Our initial version had requesters upload proof of need. We built it, looked at it, and scrapped it the same day — it puts the burden of proving poverty on a child, which is exactly what we didn't want this app to do. The code-from-a-trusted-adult model took longer to design, but it's the part we'd defend hardest.

"Subject and level" don't mean the same thing everywhere. Eighth-grade algebra in one school is "Math 1" somewhere else and "Pre-Algebra II" somewhere else again. We mapped free-text level entries to a fixed internal scale (elementary/middle/high plus numeric grade) so matching works across schools, not just within one.

Saying no to more features. Messaging, ratings, a donation leaderboard — we drafted all three and cut all three. None of them get a kid a book faster, and each one would have eaten time the core flow needed.

Accomplishments that we're proud of

-One clean path — post, search, request, verify, claim — that works end to end with no dead ends.

-A verification model that never requires a child to disclose financial information to anyone, including us.

-A request status visible to both sides at every step, so "did anything happen?" never has to be asked.

-A four-collection schema with nothing in it that exists just because it seemed nice to have.

What we learned

Scope is a design decision, not a constraint to fight. Every feature we cut made the core flow faster to ship and easier to demo.

The hardest problems here weren't technical. Deciding how to verify need without humiliating a child took more discussion than anything in the codebase.

A faked verification flow is fine for a demo, as long as the real flow it's standing in for is fully designed, not hand-waved.

What's next for BookBridge

Real intermediary accounts. Replace the hardcoded codes with actual school, library, and nonprofit logins that issue codes directly, so verification scales past a hackathon demo.

Proximity-based matching. Surface nearby donors first so pickup is a short walk or one bus ride, not a city-wide errand for a parent.

Barcode scanning at listing time. Let a donor scan an ISBN instead of typing title, subject, and level by hand — faster posting means more books actually make it into the pool.

District-level visibility. An anonymized dashboard showing where requests cluster by subject and neighborhood, so schools and city programs can see where the gaps actually are instead of guessing.

Built With

Share this project:

Updates