Building a Two-Sided Tutoring Marketplace on WordPress: The Architecture

A tutoring marketplace has to do more than list tutors. It has to verify them, match them to students, take bookings, hold the review of a session until it is actually done and paid, handle disputes, and keep a paper trail for every privileged action. This is the architecture behind one built on WordPress, and why WordPress was the right base for it.

Why WordPress, and why a plugin

The instinct with a marketplace is to reach for a framework and build from zero. For a first version with a fixed budget and a hard launch date, that is the slow path. WordPress already solves accounts, sessions, password resets, transactional email, media handling, and an admin interface. What it does not solve is the marketplace itself. So all of the marketplace logic, bookings, tutor verification, matching, payouts, lives in a single custom plugin, and WordPress stays the system of record. The plugin owns its own database tables and its own REST endpoints. The theme only renders.

Six roles, one capability model

The platform has six user types: student, tutor, admin, support, finance, and a super admin. Rather than six hard-coded checks scattered through the code, each role maps to a set of capabilities, and every protected action asks whether this user holds the capability it requires, not whether this user is an admin. Support can read a booking and message a user but cannot issue a refund. Finance can see payouts but cannot edit a tutor profile. Every privileged action is written to an audit log with the actor, the target, and a timestamp.

Identity and verification

Students and tutors each get a unique human-readable ID, separate from the internal WordPress user ID, so support can find someone by ID, surname, or subject without exposing database keys. Tutor verification documents are uploaded to a non-public directory and served only through an authenticated proxy endpoint, never a direct URL. Email verification is required before a booking can be made.

Reviews that cannot be gamed

A review can only be left against a booking that is both completed and paid. There is no free-standing review form on a profile page, and every submission passes through a moderation queue before it publishes. That gating is involved enough to be its own write-up.

A monolith, on purpose

Phase 1 runs as a single application on managed shared hosting, not a cluster of services. That is a deliberate call, recorded as an architecture decision alongside its reasons: one deployable unit, one database, no message bus to operate, and a cost a pre-revenue business can carry. The plan for scale is written down and staged: upgrade the hosting tier first, then move the database to a managed instance, then, only if the business genuinely needs it, extract bookings, payments, and messaging into their own services with WordPress left as a content and SEO shell. Building all of that on day one would have been engineering for a load that does not exist yet.

“The right first architecture is the simplest one that can carry the business to the point where it can afford a better one.”

Related