cd ../case-studies
~/case-studies/tutors-hub.md
Architectural Deep-Dive

Tutors Hub

A shipped tutor marketplace designed like a workflow engine, where the recovery path matters as much as the happy path.

Tutors Hub screenshot

title: "Tutors Hub: A Workflow Engine for Education Placement" excerpt: "Transforming a messy, manual tutoring marketplace into a secure, auditable operational pipeline." date: "Jan 2026 - Present" stage: "production" readTime: "7 min read" stack: ["Next.js", "Spring Boot", "PostgreSQL", "Supabase", "Firebase"] liveUrl: ""

What problem does this product solve?

When I first framed Tutors Hub, it looked like a familiar marketplace problem: parents need tutors, tutors need opportunities, and the platform sits in the middle. But the real problem wasn't discovery; it was operational entropy.

A tutoring lead in Dhaka is not a clean e-commerce transaction. Parents describe a moving target (curriculum, budget, urgency), and tutors have specific constraints (location, credibility, availability). The core problem I solved was converting messy, real-world tutoring demand into a structured, secure, auditable pipeline.

Instead of just building pages and forms, I built a system that reduces uncertainty at every handoff—from parent inquiry to lead intake, executive assignment, tutor shortlisting, demo verification, and commission payouts. Tutors Hub is a decision-support system and workflow engine for a high-friction service business.

Impact on Society (How people benefit)

Tutors Hub brings trust and structure to an otherwise chaotic and unregulated informal sector. Parents save time and avoid anxiety by being matched with verified, competent tutors through a transparent process. Tutors gain access to a reliable pipeline of opportunities without relying on opaque middlemen. The platform actively prevents fraud, protects sensitive contact information until trust is established, and ensures fair commission payouts, fundamentally raising the standard of educational matchmaking in the region.

User Count

Currently scaling to support hundreds of active tutor profiles and daily parent inquiries, managed by an internal team of executives through the admin portal.

Tech Stack

  • Next.js 14 (Frontend & API proxy)
  • Spring Boot (Backend workflow engine)
  • PostgreSQL / Supabase (Database & Auth)
  • Firebase (Push Notifications)
  • bKash integration (Payout layer)

Justification of Tech Stack

Why did I choose this specific stack over others?

The Bottleneck of Legacy Approaches: A traditional marketplace template (like a standard WordPress directory) would fail instantly. This business relies on state transitions, not just rendering pages. A hire request is a complex state machine (new -> in_progress -> negotiated -> matched). Legacy monolithic approaches or simple BaaS implementations would struggle with the complex, human-in-the-loop role-based access control (RBAC) required to keep sensitive data hidden until trust milestones are met.

Why this stack:

  • Spring Boot (Backend): The backend needs to own complex state transitions, authorization, scoring heuristics, and security-sensitive workflows. Spring Boot and Spring Security provide robust, enterprise-grade method-level authorization and structured state management that simple Node/Express scripts lack.
  • Next.js 14 (Frontend): Optimized for onboarding and operator UX. The server-side API proxy normalizes cookie handling and keeps browser JavaScript away from direct session tokens.
  • Supabase (Auth) + PostgreSQL: Supabase handles identity provision seamlessly, while PostgreSQL manages the relational complexity of matching tutors to vacancies, tracking duplicate leads via 30-day lookbacks, and keeping an auditable ledger for commissions.
  • Encryption for Payouts: Because this system handles commissions and bKash payouts, sensitive credentials are encrypted using AES-256-GCM. A basic BaaS couldn't model this defense-in-depth security posture effectively.