Portfolio case study

LessonBridge: Tutoring marketplace and learning operations platform

A full-stack tutoring marketplace and learning operations platform that connects tutor discovery, booking, availability, student records, messaging, files, payments, invoices, and back-office administration.

Name changed to respect NDA.

Discuss a similar platformView portfolio
Abstract tutoring marketplace platform visual with tutor profiles, booking calendar, student records, messaging, payments, and admin operations surfaces
Project scope

Full-stack product engineering across Next.js web workflows, .NET API services, relational data, booking operations, tutor tools, payments, media storage, and deployment support

4
role-specific workspaces
17
database migration steps
2
connected app surfaces
1
marketplace operations layer

Timeline

Marketplace platform build, tutor workflow expansion, and production operations setup

Tutoring operations needed one reliable product system

The product had to support tutor discovery, student bookings, availability, onboarding, payments, messages, lesson files, invoices, statements, and admin workflows without forcing the team to reconcile scattered tools.

  • Tutors needed profile, availability, request, student, file, invoice, statement, and page-builder workflows in one workspace
  • Students needed a clear path to browse tutors, book lessons, manage their profile, and keep messages organized
  • Administrators needed visibility into users, tutors, subjects, bookings, transactions, and operational records
  • The platform needed a production-ready API, database migrations, logging, file storage, and deployment structure

A connected marketplace foundation for tutors, students, and operators

LessonBridge combines a Next.js web application with a .NET 8 API so marketplace workflows, tutor tools, student activity, payments, files, and administration can move through one coordinated platform.

  • Role-aware web workspaces for students, tutors, administrators, and development operations
  • Tutor profile, availability, booking, lead, page-builder, file, invoice, statement, and settings modules
  • Student-facing tutor discovery, booking success and cancellation flows, inbox, profile, and booking history
  • API services and migrations for users, teachers, bookings, messages, payments, subjects, folders, files, reminders, and transactions

Product surfaces

What the platform brought together

The work spanned core product operations, daily user workflows, data-heavy coordination, and resilient platform management.

Tutor marketplace and profiles

Tutors can manage the public and operational pieces needed to receive lesson requests and present their offering clearly.

  • Tutor listings and profile surfaces for discovery and selection
  • Profile details, video URL, hourly rate, specialties, languages, and payout status support
  • Page builder configuration for tutor-owned public content blocks, theme settings, and lead capture

Booking and availability operations

Lesson scheduling needed clear availability, slot, booking, cancellation, and status flows across students and tutors.

  • Teacher availability calendar and slot management workflows
  • Student and tutor booking views with status, reason, subject, price, and date context
  • Booking success, cancellation, request settings, reminders, and operational admin views

Learning workspace tools

The platform gives tutors and students supporting tools around the lesson, not only the transaction.

  • Messaging and inbox workflows for student-tutor communication
  • Tutor folders and files for organizing shared learning material
  • Student records, activity, onboarding, subjects, and profile management surfaces

Payments, admin, and infrastructure

Marketplace operations were backed by payment services, administrative visibility, migrations, logging, and deployment paths.

  • Payment, invoice, statement, transaction, and payout-related workflows
  • Admin pages for users, teachers, bookings, subjects, and transactions
  • .NET API with FluentMigrator, NLog, CORS, Docker, Nginx, and Woodpecker deployment support

Buyer priorities

What mattered most to the people evaluating the platform

Prospective buyers want to know whether the work solved real workflow, adoption, reliability, data, and operations problems. These priorities shaped the product decisions.

Marketplace trust

Parents, students, and tutors need confidence that profiles, availability, bookings, messages, and payments are handled consistently.

  • Tutor profiles and discovery surfaces helped buyers understand who they were booking
  • Booking and cancellation states made lesson operations easier to follow
  • Invoices, statements, and transactions supported clearer commercial accountability

Tutor productivity

Tutors needed a practical workspace for scheduling, student management, requests, files, and profile updates.

  • Availability and slot tools helped tutors shape their bookable time
  • Folders, files, students, invoices, statements, and requests kept daily operations together
  • Page-builder and profile controls let tutors improve their public presence without a developer loop

Operational control

Marketplace operators needed enough admin depth to manage users, tutors, subjects, bookings, transactions, and production health.

  • Admin workspaces grouped key business entities into searchable management views
  • Database migrations kept schema evolution explicit as the product expanded
  • Logging, deployment scripts, and Dockerized services supported ongoing operations

System model

How the platform connects roles, workflows, and product surfaces

The product architecture brings every role into the same operating model, with shared data moving cleanly between web, mobile, media, and notification layers.

Four roles, one education marketplace

Students, tutors, admins, and operators share the same marketplace foundation through role-appropriate workflows.

Booking to lesson operations

Tutor discovery moves through availability, booking, messaging, lesson files, payment records, and follow-up operations.

Two surfaces, shared services

The web application and API coordinate through shared data, payments, storage, migrations, and deployment services.

Technology

The Stack We Used And Why

The stack section is written for buyers who need to understand the product architecture, operational trade-offs, and long-term maintainability of the system.

Web application

Used for student, tutor, and admin workflows where SEO-ready pages, role-aware routing, forms, and marketplace operations meet.

Next.jsReactTypeScriptTailwind CSSshadcn/uiLucide React

Backend API

Used to centralize marketplace business logic, authentication-adjacent workflows, bookings, payments, files, messaging, and administration.

.NET 8ASP.NET CoreControllersFluentMigratorNLogSwagger

Data and domain model

Used for structured marketplace records across users, tutors, bookings, subjects, availability, messages, transactions, files, and reminders.

MariaDBMySQLLinq2DBFluentMigratorTyped TypeScript models

Commerce and media

Used for payments, tutor payout context, profile media, lesson files, and stored learning resources.

Stripe servicesAWS S3 SDKFile upload APITutor foldersInvoice workflows

Infrastructure

Used to ship the web app and API as coordinated services with repeatable deploys, reverse proxying, SSL, and production logging.

DockerNginxWoodpecker CICertbotStandalone Next.js output

Why Next.js For The Marketplace

The product needed public tutor discovery, authenticated workspaces, forms, and role-specific routes in one web application.

  • Next.js supported both public browsing and private operational workflows
  • React and TypeScript made dense tutor, student, and admin screens easier to maintain
  • Tailwind and shadcn/ui helped keep forms, dialogs, tables, and empty states consistent

Why .NET For The API

Booking, payment, messaging, files, and administration rules benefit from a typed service boundary and explicit controllers.

  • ASP.NET Core gave the platform a stable API layer for many marketplace entities
  • FluentMigrator kept schema changes visible as modules were added
  • NLog and global exception handling improved operational visibility

Why Structured Marketplace Data

Tutoring operations depend on relational state: users, tutors, subjects, bookings, slots, transactions, messages, and files.

  • MariaDB/MySQL fit the booking, user, subject, transaction, and folder relationships
  • Typed models reduced ambiguity across API and frontend boundaries
  • Migration scripts gave the team a safer path for adding new operational modules

Delivery

How the product came together

The work moved from domain modeling to core platform delivery, mobile adoption, and operational hardening.

1

Map marketplace roles

Define how students, tutors, admins, subjects, availability, bookings, and payments should interact.

2

Build the booking foundation

Create the API, data migrations, models, availability tools, booking records, and role-aware screens.

3

Add tutor operations

Expand the workspace with profile controls, files, folders, messages, requests, invoices, statements, and page-builder tools.

4

Harden production delivery

Connect deployment, logging, CORS, migrations, Docker, reverse proxy, SSL, and operational admin screens.

Operational depth

What made the platform usable after launch

The strongest case studies are not only feature lists. They show how the system is operated, monitored, governed, and improved when real users depend on it.

Booking governance

The platform tracks scheduling decisions with status, slot, subject, student, tutor, price, and cancellation reason context.

  • Booking models include status, slot, subject, student, tutor, date, and price fields
  • Student and tutor booking views support different operational perspectives
  • Request settings and reminders extend booking beyond a single confirmation screen

Tutor business tools

Tutors can manage the operational side of their work from inside the product instead of juggling outside tools.

  • Invoice and statement workflows for commercial records
  • Folders and files for organizing learning material
  • Profile, video, specialty, language, and page-builder controls

Production support foundation

The API and deployment setup were designed for repeatable releases and easier issue investigation.

  • FluentMigrator-backed database evolution
  • NLog, global exception handling, and request diagnostics
  • Docker, Nginx, Certbot, and Woodpecker deployment support

Results

The measurable and observable lift from the work

The strongest improvements are the ones a buyer can connect to daily work: fewer disconnected tools, safer operations, clearer workflows, and more reliable product behavior.

4 roles

Role-Aware Operations

Students, tutors, administrators, and operators moved into purpose-built workflows instead of one generic management surface.

17 migrations

Expanded Domain Model

The platform evolved through explicit migration steps covering bookings, profiles, messaging, files, folders, invoices, reminders, and transactions.

Unified

Tutor Workspace

Availability, requests, students, messages, files, invoices, statements, profile, and settings came together in one tutor-facing product area.

Dockerized

Repeatable Deployment

The web app and API were prepared for coordinated production deployment with Docker, reverse proxying, SSL, and CI support.

Outcome

A stronger operating system for education marketplace operations platform

The platform reduced tool fragmentation and gave each role a clearer path from live activity to day-to-day action.

A connected tutoring marketplace foundation instead of separate tools for discovery, scheduling, files, payments, and administration

Tutor workflows that combine profile management, availability, bookings, students, requests, files, invoices, and statements

Student workflows that support tutor discovery, lesson booking, inbox, profile, and booking history

A production operating layer with API migrations, logging, deployment automation, storage, and administrative visibility

FAQ

Frequently Asked Questions About LessonBridge

Answers about the education marketplace operations platform scope, platform model, technology choices, operational workflows, and related build patterns.

What Kind Of Education Platform Does LessonBridge Represent?

LessonBridge represents a tutoring marketplace and learning operations platform with tutor discovery, booking, availability, student records, messaging, files, invoices, payments, and administration.

Why Was Custom Software Useful For This Tutoring Model?

Custom software made sense because the business needed marketplace discovery, tutor-owned operations, student booking workflows, payments, files, and admin controls to work from one shared domain model.

How Did The Platform Improve Operational Depth?

The system expanded from core user and booking flows into availability management, tutor profiles, messaging, files, folders, page-builder tools, invoices, statements, reminders, and transaction oversight.

Can The Same Pattern Support Other Learning Businesses?

Yes. The same product pattern can support tutoring marketplaces, coaching networks, education agencies, test-prep businesses, creator-led classes, and specialist learning programs.

Related services

Build a similarly ambitious product without starting from a blank page.

We can help scope the web, mobile, AI, media, and operating layers needed for your own platform.

Start a project inquiry
Custom software developmentWeb app developmentMVP development companyLegacy software modernizationCloud migration services