← all projects
Marketplace

Pracket

Tutor-meets-student marketplace where parents and students find verified tutors, pay a one-time connection fee to open a conversation, and communicate entirely on-platform. Tutor identities stay masked until both sides choose to share contacts.

Pracket

Connection-fee marketplace that monetizes introductions, not lessons: verified tutors, masked identities, on-platform real-time chat, and a trust team for moderation. Express + Socket.io backend, React frontend.

React
TypeScript
Node.js
Express
MongoDB
Socket.IO

Problem Statement

Tutoring marketplaces have a classic disintermediation problem: once a parent and tutor connect, they take the relationship (and the money) off-platform, and the marketplace earns nothing. Charging a percentage of every lesson is also hard to enforce. Pracket's insight: monetize the introduction, not the lesson — and protect both sides with verification and identity masking until they choose to trust each other.

Proposed Solution

Pracket is a tutor-meets-student marketplace where parents/students discover verified tutors, pay a one-time connection fee to open a conversation, and communicate entirely on-platform via real-time chat. Tutor identities stay masked until both sides opt to share contact details. The platform earns on connections, not on lesson transactions — and a trust team handles verification and moderation.

Full Solution Details

Feature-per-domain on the backend: auth, tutors (profiles, credentials), search (by subject/level/location/format/price/verification), shortlist (save tutors to compare), connections (the paid introduction), messages (on-platform real-time chat), posts (tutor "Sunday notes"), reports (moderation), and admin/trust. Email receipts and trust-team notifications go out via Nodemailer.

Technical Documentation

Backend — Node ≥20 + Express + TypeScript (strict) + MongoDB (Mongoose), with Socket.io scoped to the conversation feature only (real-time where it matters, plain REST everywhere else). Layered controller → service → model → routes, one folder per feature, with requests/ holding express-validator rule arrays (plus Zod), JWT bearer auth with role claims in the payload, and a strict, always-on response envelope ({success, data, message} / {success:false, error, details?}). A ServiceResult type and MESSAGE_KEYS standardize outcomes. Security via helmet, CORS, compression, rate limiting. Notably, the backend never handles file bytes — the frontend uploads directly to an external file service and the backend stores only the returned key.

Frontend — React + TypeScript + Vite + Tailwind, TanStack Query for server state, Socket.io client for chat, Lucide icons, and the author's meemaw utilities. Built from a documented frontend build plan with QA handoffs.

Tech Stack

Node.js ≥20, Express, TypeScript, MongoDB/Mongoose, Socket.io, Zod, express-validator, JWT, Nodemailer, helmet, compression (backend); React, TypeScript, Vite, Tailwind, TanStack Query, Socket.io client, meemaw (frontend); external file service for uploads.

System Design

Parent/Student ──search──► verified tutors (identity masked)
        │
        ▼
   Pay connection fee ──► Connection opened
        │
        ▼
   On-platform chat ◄── Socket.io (conversation feature only)
        │                        REST for everything else
        ▼
   Optional: both opt-in → reveal contact details

   Backend: feature folders (auth/tutors/search/shortlist/connections/
            messages/posts/reports/admin) · JWT role claims ·
            response envelope · ServiceResult · Nodemailer (receipts/trust)
   Files:  FE → external file service → key stored in DB (backend never sees bytes)
   Trust team: verification + moderation (reports/admin)

Smart Architectural Decisions

  • Monetize the connection, mask the identity. The whole product hinges on charging for the introduction and keeping tutors anonymous until mutual opt-in — a clever answer to marketplace disintermediation and a privacy/safety feature in one.
  • Socket.io only where it's needed. Real-time is scoped to the conversation feature; the rest stays simple REST. Resisting the urge to make everything real-time keeps the system lean.
  • Backend never touches file bytes. Direct-to-file-service uploads (store only the key) keeps the API stateless about binaries, cheaper, and more scalable — and reuses his file-service infrastructure pattern.
  • Strict, uniform response envelope + ServiceResult + MESSAGE_KEYS make every endpoint predictable and i18n-ready.
  • Trust team as a first-class actor. Modeling verification/moderation (reports, admin) into the domain shows the author designed for marketplace safety, not just the happy path.

Impacts

A marketplace with a defensible business model (paid, masked introductions), real-time on-platform messaging, verified-tutor trust, and a clean feature-sliced backend — built from documented plans with QA handoffs.

Demonstrated Skills

Marketplace + two-sided-platform design (incentives, disintermediation, trust/safety); selective real-time (Socket.io scoping); feature-sliced backend architecture with uniform response contracts; auth + RBAC via JWT claims; stateless file handling via external service; React + TanStack Query + Socket.io frontend; planning/QA-handoff process.

Notes

  • Business-model thinking: the connection-fee + identity-masking design is genuinely clever product strategy — it shows the author reasons about incentives and disintermediation, not just CRUD.
  • Trust & safety as a domain: modeling a verification/moderation "trust team" (reports, admin) signals maturity about real marketplace risks.
  • Architectural restraint: scoping Socket.io to only the chat feature, and keeping file bytes out of the backend, are both "do less, scale better" decisions that read as senior.
  • Process discipline: documented build plans + QA handoffs show he can work in a structured, team-style workflow.
  • Uniform response envelope + ServiceResult = consistent, i18n-ready API design.
Ask me anything