More project photos (2)
The problem
BookLoop, the peer textbook exchange portal, exists because the campus used-book trade runs on noticeboards and WhatsApp groups — channels where listings go stale, prices are guesswork and buyers cannot verify the edition. The portal replaces that chaos with a structured marketplace limited to one campus: sellers list a textbook by its ISBN-13, the system validates the check digit and confirms title, author and edition, and the seller adds a condition grade, photos and an asking price. Buyers search by title, author, ISBN or branch, compare each asking price against the printed MRP, and open a negotiation chat where offers are structured cards with amounts and a 48-hour expiry rather than free-text haggling. Accepting an offer creates a deal record, and both sides pick a campus meetup spot and time for handover. Because every step — listing, offer, acceptance, meetup — happens inside one system, disputes about edition or price have a written record both sides can point to.
This is a built-to-order software project: the complete portal — Next.js frontend, Express REST API, MySQL schema, negotiation chat with structured offer cards, seller dashboard, and the full viva kit (report, PPT, Q&A) — is built fresh for you.
Builder note from the demo build: public ISBN cover lookups are unreliable for Indian editions — the lookup returned 1×1 placeholder images for several ISBNs and, worse, served a classroom photograph as the "cover" of one textbook. Every cover used in the demo was visually verified before use, and the production build treats cover images as optional decoration, never as edition evidence; the ISBN check digit is the source of truth.
Seller enters the ISBN-13; the mod-10 check digit (weights 1 and 3) is validated before the listing can go live.
Follow the working sequence
How it works
End to end, a book moves from a senior's shelf to a junior's bag in four stages. Listing: the seller enters the ISBN-13, the system validates the check digit and confirms the edition, then the seller adds a condition grade, photos, asking price and a description — the listing appears on the campus feed immediately. Browsing: buyers search by title, author, ISBN or branch filter, and each card shows the asking price next to the printed MRP with the saving percentage computed automatically. Negotiation: the buyer opens a chat thread and sends an offer card with an amount; the seller can accept, decline or counter, each response recorded in the thread, and every offer lapses 48 hours after it is sent. Meetup: on acceptance the listing freezes, a deal record is created, and both sides choose a campus spot and time slot — handover and cash/UPI payment happen in person, and the seller marks the deal complete.
- The seller signs up with a college email address; the API issues a signed JWT session and marks the profile campus-verified.
- The seller posts a listing: the ISBN-13 check digit is validated by the mod-10 algorithm, the edition is confirmed, and condition grade, photos, asking price and description are stored against the listing row.
- Buyers browse the feed or search by title, author, ISBN or branch; each card renders the asking price beside the printed MRP with the saving percentage computed at render time.
- The buyer opens the listing's negotiation thread and sends an offer card carrying the amount and a 48-hour expiry timestamp.
- The seller accepts, declines or counters from the chat or the dashboard; acceptance atomically creates a deal record and freezes the listing so it cannot be sold twice.
- Both sides pick a campus meetup spot and time slot from the scheduler; they meet, exchange the book for cash/UPI, and the seller marks the deal complete, archiving the listing.
Tech stack:
- Next.js 14 (React) frontend
- Node.js · Express REST API
- MySQL 8 (InnoDB)
- JWT authentication (college-email signup)
- Socket.io live chat with polling fallback
- ISBN-13 check-digit validation (mod-10)
- Tailwind CSS
- bcrypt password hashing
| Parameter | Value |
|---|---|
| Deployment scope | 1 campus per deployment (design target) |
| Offer expiry | 48 hours from sending (configurable at build time) |
| ISBN validation | ISBN-13 mod-10 check digit, weights 1/3 (algorithm value) |
| Condition grades | 3 grades: Like New, Good, Acceptable |
| Chat transport | WebSocket with 5-second polling fallback (design target) |
| Auth | JWT sessions, bcrypt cost factor 12 (design target) |
| Demo seed data | 12 listings across 6 branches, 3 chat threads (measured in the demo build) |
| Listing-post flow | Approximately 5 ms from filled form to live listing (measured in the demo build, headless Chromium) |
| Meetup spots | 4 seeded campus spots (configurable) |
Project features
The portal's four strongest capabilities are ISBN-verified listings, structured offer negotiation, the seller dashboard, and meetup coordination. ISBN verification means a seller types the 13-digit code and the check-digit algorithm confirms it before the listing goes live, so a buyer never receives the wrong edition of a textbook — the single most common complaint in campus book trades. Structured negotiation replaces haggling with offer cards: each offer states an amount and expires after 48 hours, counter-offers link into a visible chain, and accepting one freezes the listing and creates a deal record. The seller dashboard shows views, active offers and deal status for every listing in one table, so nothing needs a separate spreadsheet. Meetup coordination closes the loop — after a deal, both sides pick from campus spots and time slots, and the agreed handover appears as a card in the chat thread that both can see.
- [ISBN-13 check-digit validation] (Implemented) Every listing's ISBN-13 is validated with the mod-10 check-digit algorithm (alternating weights 1 and 3) before it goes live, and the confirmed title, author and edition are shown to buyers — wrong-edition listings are rejected at posting time.
- [Structured offer and counter-offer cards] (Implemented) Offers are data, not chat text: each card carries an amount, sender, timestamp and a 48-hour expiry countdown. Counter-offers chain visibly in the thread, and the full history is preserved for both sides.
- [Seller dashboard] (Implemented) One table shows every listing with view counts, active offers awaiting reply, deal status and quick actions — accept, decline or counter without opening each chat.
- [Branch, condition and price search] (Implemented) Buyers filter by branch, condition grade (Like New, Good, Acceptable) and price range, and search across title, author and ISBN; each card shows the asking price against the printed MRP with the saving percentage computed automatically.
- [Campus meetup scheduler] (Implemented; spot list configurable) After a deal is agreed, both sides pick from a campus spot list (library steps, canteen porch, hostel gate) and time slots; the agreed handover renders as a card in the thread.
- [Deal records and frozen listings] (Implemented) Accepting an offer atomically creates a deal record and freezes the listing so no second buyer can claim the same book; the seller marks the deal complete after handover.
- [College-email signup with JWT sessions] (Implemented) Accounts are tied to a college email domain, and API access uses signed JWTs — the same auth model the demo, page and report all describe.
- [Price-trend hints] (Future scope, not implemented) Once a campus accumulates sale history, the portal could suggest a fair asking price from past deals for the same ISBN — designed but not built in this version.
What is included
- Complete Next.js frontend: browse feed, listing detail, negotiation chat, sell flow, seller dashboard
- Node.js/Express REST API with JWT auth and the negotiation engine (offers, counters, 48-hour expiry, deal records)
- MySQL 8 schema, migrations and seed data
- ISBN-13 validation module with check-digit algorithm
- Campus meetup scheduler with configurable spot list
- Project report PDF (10-section), PPT presentation and viva Q&A document
- Deployment guide for a single-campus pilot
Limitations & prerequisites
- One deployment serves one campus; running it for multiple colleges needs separate instances with separate databases.
- No online payment is handled — handover is cash/UPI in person, so payment disputes are outside the system.
- ISBN edition lookup needs internet at listing time; offline, the seller falls back to manual title/author entry.
- Chat is text plus structured offer cards only — no voice/video calls and no photo annotation inside threads.
- The 48-hour offer expiry is set at build time per deployment, not adjustable per user or per offer.
- Condition grades are seller-declared; the portal does not physically inspect books, so buyer judgement at meetup still matters.
Frequently Asked Questions
How does the price negotiation actually work?
Through structured offer cards inside the listing's chat thread, not free-text haggling. The buyer sends a card with an amount; the seller accepts, declines or counters; each card shows a 48-hour expiry countdown and the whole chain stays visible. Accepting an offer creates a deal record and freezes the listing so the book cannot be promised to two buyers.
How does ISBN verification prevent wrong-edition sales?
Every ISBN-13 is run through the mod-10 check-digit algorithm before the listing goes live, and the confirmed title, author and edition are displayed to buyers. A mistyped or fake ISBN is rejected at posting time, so the most common campus complaint — receiving the wrong edition — is caught before money changes hands.
What stops a seller accepting two offers for one book?
The database update is atomic: accepting an offer creates the deal record and freezes the listing in the same transaction. Once frozen, the listing disappears from search and its chat threads show the deal status, so a second acceptance is technically impossible.
Is payment handled inside the portal?
No. Handover and payment happen in person at the agreed campus meetup — cash or UPI between the two students. The portal records the agreed price and the meetup, but deliberately stays out of the money flow, which keeps the build simple and dispute-free by design.
Is this project suitable for a final-year project?
Yes — for Computer Science, IT and related branches. It demonstrates full-stack development (Next.js, Express, MySQL), real-time chat, transactional deal logic, authentication, and a genuinely usable campus product with a clear problem statement. The negotiation engine gives strong viva material on state management and database transactions.
Components & software requirements
- Next.js 14 (React) frontend
- Node.js · Express REST API
- MySQL 8 (InnoDB)
- JWT authentication (college-email signup)
- Socket.io live chat with polling fallback
- ISBN-13 check-digit validation (mod-10)
- Tailwind CSS
- bcrypt password hashing
Delivery information
Built-to-order project. Delivery timeline is shared after order confirmation based on current queue.
Support terms
Complete documentation, setup guide, and viva preparation included. Support for setup and explanation provided.
Download free synopsis (PDF)
Enter your name and WhatsApp number — the synopsis PDF downloads immediately. We may send occasional project updates on WhatsApp; no spam.