
Multi-vendor commerce
An online marketplace for cakes, sweets and gifts, where sellers take orders for delivery or pickup.
One marketplace running three separate markets: hiring freelancers, buying courses, and finding software.

ZIXXT is a marketplace that does the job of three separate websites at once. The Services section works like Fiverr or Upwork, where buyers hire people for a piece of work. The Education section works like Udemy, selling courses at a fixed price and also offering tutoring style support packages. The Softwares section works like Capterra, a directory where buyers compare software products and click through to buy on the vendor's own site. The three share only the login, the admin panel and the infrastructure. Everything else is separate: their own categories, their own fee rules, their own order flow, and their own colour theme.
On the Services side, a buyer browses or searches, opens a seller's profile to see their level, rating, languages and past work, and picks one of four package tiers. Before the work starts the seller can ask the buyer a set of questions, so nothing begins with missing information. Bigger jobs get split into milestones that the buyer pays one at a time. When the seller delivers, the buyer either accepts it or declines with a written reason, and the seller revises and sends it back. If the buyer says nothing for three days the order approves itself, so a seller is never left waiting forever. Delivered files can be watermarked until the buyer accepts, and if the seller is late the platform applies an automatic discount and credits it to the buyer's account.
Sellers get a dashboard showing their real balance, their current level and every order's live status. They can create postings, mark themselves as not accepting orders, set an auto reply, ask the buyer for more time, or ask to revise the price if the job grew. Sellers move up through four levels, Regular, Silver, Gold and Platinum, recalculated every week from the last 180 days of revenue, orders and review scores, so a level can go down as well as up. Buyers get their own dashboard with active orders, items waiting to be reviewed, their account credit, open requests, unread messages and bookmarked sellers.
The Education section sells courses laid out as chapters and topics, each with its own videos, documents, articles, assignments and quizzes. After buying, the buyer has ten days to download the files before they are removed, with reminders at ten, three, two and one day left. Education also offers support packages that work exactly like the Services section, with different fee rates. The Softwares section is a referral model instead: software companies pay for a listing on a monthly or yearly plan, and their listing stays visible only while that plan is paid. Standard and Premium plans also show them who viewed their profile.
Money is the part that took the most care. Buyers pay on ZIXXT's own branded Stripe checkout rather than being sent away to a hosted page, and the money sits in the platform's account until the order completes. Sellers are then paid either automatically through Stripe Connect, or through PayPal and Wise using bulk files the admin exports and uploads. Earnings live in an append only ledger, so a balance is always the sum of its rows and can never drift out of step with reality. Every payment produces a numbered PDF invoice or receipt, with all figures frozen at the moment of payment so a later fee change never rewrites history. Tax is 5 percent worldwide plus a full province by province calculation for Canada.
Buyers and sellers can talk in a chat. Sellers can send four kinds of offer inside it: a straight quote, a milestone quote, a meeting quote, or an after sales offer. The chat watches for contact details being shared and warns in real time. If something goes wrong, either side can open a dispute, which the two of them can settle between themselves, or escalate to an admin who joins the thread and settles it with the refund engine built in.
The platform also sells advertising. Ad slots sit at fixed positions on the first ten search pages, priced by how far up the results they appear, and are booked per category for a date range. A database level constraint makes double booking the same slot physically impossible. On top of that sit paid seller memberships that unlock buyer requests and lower commission, listing boosts, a referral scheme, bookmarks, and reviews scored on different criteria in each of the three sections.
I built the whole platform, from the Supabase database schema and the interface routes through the pricing, payout and dispute logic to the buyer, seller and admin interfaces. That covers 37 database migrations, a 22 page admin panel with role based employee permissions and an audit log that survives an employee being deleted, and 16 report types across three user roles all generated by one shared engine.
Buyer money had to be held safely and then released to sellers through three different payout routes.
Built an escrow model where funds stay in the platform Stripe account until completion, then go out either automatically through Stripe Connect or as bulk CSV files formatted for PayPal and Wise. Earnings sit in an append only ledger, so a balance is always the sum of its rows and can never drift out of step.
Two buyers booking the same advert slot over overlapping dates would break the whole advert system.
Made it impossible at the database level with a btree_gist exclusion constraint on category, page, slot and date range, so the second booking simply cannot be written.
Order status, revenue totals and reports kept disagreeing because each screen worked them out its own way.
Stopped storing anything that can be derived. Past due and open request are computed by one shared function, ratings are maintained by a single Postgres trigger, and revenue is summed from invoices rather than orders, since a milestone order never marks itself fully paid.
Stripe secret keys had to live in the database without becoming a liability.
Encrypted them with AES-256-GCM, made them write only in the admin panel, and stored a key fingerprint on each payment intent so keys can be rotated cleanly. A tampered value fails to decrypt instead of returning junk.
The spec required the buyer to confirm payment again on every milestone, which normal saved card flows skip.
Gave each milestone its own Stripe Payment Intent with setup_future_usage set to on_session, which keeps the card saved for convenience while still forcing the confirmation step the spec asked for.
A software listing could go live before its paid plan was confirmed, leaving listings that could never appear in search.
Reordered the flow so the plan is bought before the listing form is submitted, and the expiry date is written last. If that final step fails, the listing rolls back rather than being left in a state where it can never show up.
New features kept shipping without anyone noticing their notifications were never wired up.
Put every notification event in one catalogue that declares which channels it uses, with a test that fails if an event makes no channel decision. Email templates live in one file with a shared layout, so a new email cannot drift away from the rest.