Live: https://www.maidhive.app Role: Solo product designer & full-stack engineer — discovery, product spec, UX, UI, backend, payments, QA, deployment. Timeline: Apr 2026 – Aug 2026 Stack: Next.js 16 (App Router) · React 19 · TypeScript · Prisma · PostgreSQL (Supabase) · Supabase Auth & Storage · Stripe Connect · Tailwind CSS · Vitest · Playwright · Vercel

Booking a cleaner in Cyprus was a WhatsApp-and-cash market: no vetting, no clear pricing, no recourse when a cleaner didn't show up, and no way for good cleaners to build a reputation that travels with them. Both sides carried risk that neither could price.

The design brief was therefore not "build a booking form." It was: make trust the product. Every screen and every backend rule had to answer one of two questions — can I trust the person coming to my home? or will I actually get paid for the work I did?

Search and filter approved cleaners by location, service type, and availability, with saved favourites and saved addresses.

Real-time availability that reads each cleaner's weekly schedule, blocked time, and existing bookings before offering a slot — no double bookings, no phantom availability.

Transparent price preview before commitment (service type, bedrooms, bathrooms, extras) so the number never changes at checkout.

The card is authorized at booking, not charged — money only moves after the job is completed and released.

In-booking messaging with the cleaner, booking photos, ratings and reviews, and a "report a problem" path that opens a formal dispute.

Guided onboarding: profile, service areas, KYC document upload to private storage, phone verification, and Stripe Connect payout onboarding — all gated behind admin approval before the profile goes live.

Job request inbox with a time-boxed accept window, availability and blocked-time management, and Google Calendar sync so personal commitments block marketplace slots automatically.

Earnings dashboard covering authorized, captured, released, and paid-out states, so a cleaner can always see exactly where their money sits in the pipeline.

GPS-verified job starts, which feed both dispute evidence and the reliability score.

Cleaner approval and KYC review queue, user management and suspension, and full booking inspection with a per-booking action event timeline.

Ops queues surfacing everything that needs a human: failed payments, stuck authorizations, unresolved disputes, expiring booking requests.

Dispute resolution with evidence review and partial or full refund handling, with financial adjustments reconciled back onto the booking.

Escrow-style payments on Stripe Connect. Bookings use manual-capture PaymentIntents: the client's card is authorized when they book, captured when the job completes, and transferred to the cleaner's connected account minus the platform fee. A reconciliation job runs every 5 minutes to sync Stripe state back into the database, capture eligible payments, and repair any booking whose payment drifted out of sync — because webhooks alone are not a durable source of truth.

A reliability engine with real rules, not vibes. "Super Cleaner" is earned against explicit criteria — 20+ completed and released bookings, 4.6+ average rating, zero admin-confirmed no-shows in 60 days, a sub-10% cancellation rate, and a 90%+ on-time rate across at least 10 GPS-verified starts. Late cancellations are bucketed by notice window, grouped into same-day incidents, and escalated into expiring strikes on repeat behaviour. The whole policy was written up as an implementation source of truth before a line of it was coded, so the rules stay auditable and identical across the UI, the API, and the admin console.

A booking state machine, not a status column. Bookings move through pending, accepted, confirmed, in-progress, completed, cancelled, and expired states, each with its own payment consequence, notification fan-out, and cancellation policy. Every transition is written to an immutable action-event log — which is what makes a dispute resolvable months after the fact.

Layered architecture. Routes stay thin; services own the business rules; repositories own data access. 84 versioned (/api/v1) endpoints, validated at the boundary with Zod, with role-based authorization enforced server-side rather than in the UI. Sensitive documents (KYC, ID, dispute evidence) live in private storage behind signed, permission-checked access.

Tested like it handles money, because it does. A documented test strategy with a unit → integration → E2E pyramid: Vitest for policy, pricing, and state logic; Playwright for authenticated role-based journeys across client, cleaner, and admin at mobile (390px), tablet (768px), and desktop (1440px) widths. CI gates every push on the full suite plus a production build and type check, and releases require a preproduction regression run plus a per-role UAT checklist signoff.

The interface is deliberately calm and information-dense rather than playful — deep navy and white with a single yellow accent reserved for the primary action on any screen. Each role gets a purpose-built dashboard that opens with the answer to that role's most urgent question: when is my next clean? for clients, what needs my response, and what have I earned? for cleaners, what is broken right now? for admins. Money states are always spelled out in plain language ("Completed – Released", "You have not been charged", "Payout paused pending case resolution"), because ambiguity about payment is the fastest way to lose both sides of a marketplace.

This wasn't a UI project with a database bolted on. The hard parts were the invariants — that a slot can't be double-booked, that a cleaner can't be paid twice, that a payment can't be silently orphaned between Stripe and Postgres, that a cancellation two hours before a job carries a different consequence than one two days before. I designed those policies, documented them, implemented them, and built the test and reconciliation infrastructure that proves they hold.