Build a two-sided marketplace with Stripe Connect payouts

Build Fixly, a two-sided marketplace connecting independent home-repair contractors with homeowners booking one-off jobs, where money actually changes hands through the platform — this is not a lead-gen directory, it is a real transaction flow with a platform fee.

PRODUCT
independent home-repair contractors list what they offer; homeowners booking one-off jobs pay for it through the app. Fixly takes a 12% cut of every transaction and pays the rest out to the provider.

DATA MODEL
- Provider: id, user_id, display_name, bio, stripe_connect_account_id, connect_onboarding_status (not_started, pending, or complete).
- Listing: id, provider_id (references Provider), title, description, price, is_active.
- Order: id, listing_id (references Listing), buyer_id, provider_id, amount, platform_fee_amount, status (pending, paid, completed, refunded, or disputed), stripe_payment_intent_id, created_at.
- Review: id, order_id (references Order), rating, comment, created_at — only writable once an Order's status is completed.

STRIPE CONNECT FLOW
Use Stripe Connect Express accounts, not standard or custom accounts — Express gives providers a Stripe-hosted onboarding flow, which is the right fit here since this app is not trying to fully white-label the payments experience. When a Provider signs up to sell, generate a Stripe Connect Express onboarding link and redirect them to it; set connect_onboarding_status to pending until Stripe's webhook confirms the account can accept payouts, then flip it to complete. A Listing cannot go live — is_active cannot be set true — while its Provider's connect_onboarding_status is anything other than complete; enforce this in the database, not only by hiding a toggle in the UI. On checkout, create a PaymentIntent with an application_fee_amount equal to 12% of the order total and transfer_data pointing at the provider's connected account, so the split happens inside Stripe's own transfer at the moment of payment rather than as a manual payout step your app has to calculate and trigger later.

TRUST AND SAFETY
Buyers can only leave a Review after their Order reaches completed status — never before, and never on behalf of an order that was refunded or disputed. Give an Order a disputed status path and a simple admin view listing every disputed Order with its Stripe dispute ID, so a human can actually act on it instead of it disappearing into a support inbox.

SCREENS
1. Browse/search listings, filterable by category and price. Seed with sample categories: Plumbing, Electrical, Appliance repair, Painting.
2. Listing detail with a "Buy" or "Book" button leading to Stripe Checkout for the actual charge.
3. Provider dashboard: their listings, incoming orders, payout status, and the Connect onboarding link if still incomplete.
4. Buyer order history with review prompts on completed orders.
5. A minimal admin view: all orders, filterable by status, with the disputed-orders list above surfaced first.

CONSTRAINTS
Use Lovable's Supabase integration for the data model and auth; use Stripe Connect Express for payments, not a custom in-app wallet or ledger you'd have to reconcile by hand. #E8562A (burnt orange), warm and trustworthy, not corporate blue Do not let a Listing accept payment while its provider's onboarding is incomplete — that single rule is what actually protects you from a payment succeeding with nowhere valid to send the payout.