After the limo plugin, my next build carried a different kind of weight. MaidsMe Pro is a job marketplace for domestic workers in the UAE market, maids, nannies, drivers, cooks, caregivers, connecting people looking for work with people looking to hire. The code challenges were familiar by now. What was new was that every row in this database is a person in a vulnerable position, and that fact shaped the architecture more than any technical preference. This post is the idea, and the decisions that weight forced before I wrote a line.
A marketplace has three actors, and naming them precisely was the first design act. Job seekers, who register, build a profile, and upload documents. Employers, who browse and hire. And the admin, who controls everything in between. The word between matters, because the first structural decision was that this platform is admin-mediated, nothing a worker submits becomes public until a human approves it, and no employer reaches a worker directly without the admin in the loop. That is unusual for marketplaces, which normally optimise for direct connection, and it exists here because of who the users are.
That decision lives in the schema. A profile is not just data, it is data plus a status, and the status list was designed before the tables:
// The profile lifecycle, decided before any table was created
// draft -> worker still filling in
// pending_approval -> submitted, awaiting a human
// approved_visible -> live on the site
// approved_hidden -> approved but temporarily unlisted
// rejected -> not accepted
// suspended -> pulled after being live
Six statuses instead of a visible yes or no, because real moderation needs the in-between states, a profile can be fine but hidden while the worker travels, or suspended pending a question, without destroying the data. Every public query in the platform then carries the same non-negotiable condition:
$profiles = $wpdb->get_results($wpdb->prepare(
'SELECT id, full_name, profession, experience_years, summary
FROM ' . $this->table_profiles . '
WHERE status = %s ORDER BY approved_at DESC',
'approved_visible'
));
Notice also what that SELECT does not fetch, no phone, no email, no documents. The columns a public query touches were themselves a privacy decision, which grows into this platform’s defining rule a few posts from now. And one more early commitment, sensitive fields like phone numbers would be stored encrypted, readable only through the admin’s screens, because a database backup or a leak should not be a directory of vulnerable people’s numbers.
A few things people ask me about this
Why not let profiles go live instantly like other marketplaces? Because the users are workers in a vulnerable position and the market is prone to abuse. A human approval gate trades growth speed for safety, and for this platform that trade is the whole point.
Why six statuses instead of an is_visible flag? Because moderation reality has middle states, approved but hidden, suspended pending review, and a boolean forces you to fake those with deletions and re-entries. Statuses preserve data and history.
Next
With the actors and rules named, I designed my first version, two full login systems with a chat between them. It was thorough, symmetrical, and, as the next posts admit, wrong.
