Forge Market

Forge Market was my first full-time build, a marketplace for digital products (Shopify themes, WordPress templates, code templates, UI kits, design assets). I built it because I wanted to work through a product with real financial flows: sellers, buyers, commissions, payouts, disputes, and file delivery. The goal was not to compete with Gumroad; it was to build something complete enough to teach me what I did not know.

Sellers apply to list products and choose which categories they want to sell in. Once approved, they can list products with three pricing tiers, regular, commercial, and business, each with different use rights and different price points. Files are stored privately in S3; buyers receive a short-lived presigned download URL after purchase. Each product type has its own metadata model: a Shopify theme stores compatibility versions and language support; a WordPress template stores builder compatibility and PHP version; a design asset stores file types and tool compatibility. Commission splits are 65% for standard listings and 70% for exclusive ones.

Quality control happens at two points. When a seller applies, a Trigger.dev background job runs an AI review of their application, categories they want to sell in and links to their existing work, and stores the result for the admin. The admin sees the GPT summary alongside the raw application, which makes the decision faster and more consistent. When a product is submitted, a second job downloads the actual product file from S3 using a short-lived presigned URL, analyses its structure and content, and runs a type-specific GPT validator: Shopify and WordPress themes are checked against theme structure conventions; code products are validated against their declared programming languages; design assets are checked for file type and tool compatibility. The review is stored on the product record. The human admin still approves, but with context they would otherwise have to generate manually.

Getting money to sellers reliably was the most complex part of the system. When a sale completes, seller earnings are computed at that moment based on the commission rate, and a payout release date is set. A scheduled job runs periodically and releases earnings to the seller's balance once the release date has passed, but only if the order has no active dispute. If a dispute exists, the earnings stay frozen. Once the dispute is resolved and a short grace period has passed, the job picks them up on the next run. When a seller requests a payout, the request is logged as pending. A separate job processes all pending requests in parallel using Promise.allSettled, calls the PayPal Payouts API for each one, and writes every attempt, success or failure, to an audit log. If a payout fails, the amount is atomically returned to the seller's balance so nothing is lost. I chose PayPal over Stripe Connect because the target seller base was PayPal-native in the relevant markets; the tradeoff was a more involved payout implementation.

Marketplace payment logic is an order of magnitude more involved than standard e-commerce. You are not just processing a payment, you are splitting it, holding a portion of it, handling disputes that can reverse it, and eventually paying it out through a third-party API that can fail independently. Getting the payout failure recovery right (atomic balance restore, full audit log, per-request failure isolation with Promise.allSettled) took real thought. On AI moderation: it works well as a first pass. The GPT review gives the admin enough context to approve or reject in seconds rather than manually unzipping and inspecting every file. But the human is still in the loop, the AI surfaces signals, the admin makes the call. That turned out to be the right division of responsibility.