01 / 04 · System overview
Selected work
Client delivery · 2023 – 2024
Multi-Vendor Marketplace
A multi-vendor commerce marketplace delivered across a Flutter buyer app, seller sales channel, and admin dashboard, with Shopify-backed carts/checkout, product sync, search indexing, and webhook-backed order visibility.
01 Scope
The product context behind the work.
Problem
The marketplace needed one coherent operating system across buyers, sellers, and internal operations. Buyers needed a clean way to discover many stores and products, add items to store-specific carts, and check out. The team needed seller onboarding, catalog control, search, merchandising, and reliable order visibility without exposing separate disconnected tools.
My contribution
- Built across the Flutter buyer app and marketplace API flows for store discovery, product detail, wishlist, per-store carts, checkout handoff, and customer orders
- Worked with a Shopify-backed seller sales channel and Storefront/Admin APIs so connected stores could publish products and receive checkout/order flows
- Supported admin and merchandising workflows for stores, categories, collections, carousels, product sync, customers, and orders
- Connected product/order state through MongoDB + Prisma, Typesense search indexing, Cloudflare-hosted product media, Stytch customer auth, and webhook-backed updates
02 Approach
Important engineering decisions.
The product is a multi-vendor commerce marketplace built across several connected surfaces: a Flutter buyer app, a seller sales channel, a marketplace API layer, and admin/merchandising tools. The challenge was keeping those surfaces aligned around the same stores, products, carts, customers, and orders.
On the buyer side, the Flutter app covers the full shopping path: discovering stores and categories, browsing products, viewing product details, managing wishlist and cart state, checking out, and viewing orders. The cart flow is store-aware: the app sends the selected variant and store to the API, which creates or updates the right Shopify cart and returns a checkout URL for the buyer.
Behind that, connected stores come through a Shopify sales channel. Product listings, shop updates, and orders flow back through webhooks, then the marketplace layer persists the relevant state in MongoDB through Prisma. That gives the admin tools one place to manage stores, categories, collections, carousel merchandising, customers, products, and orders.
The architecture also includes the operational pieces that make the marketplace usable at scale: Stytch-backed customer sessions, Typesense product indexing, Cloudflare-hosted product media, webhook-backed order records, and analytics/error monitoring around purchase and admin flows.
03 Evidence
Evidence chapters.
02 / 04 · Product journey
Per-store checkout and order visibility
03 / 04 · System boundary
Catalog synchronization loop
04 / 04 · Delivery / verification
Contribution across connected surfaces
04 Delivered & verified
What the public proof supports.
Delivered scope
Buyer journey
Discovery -> product -> per-store cart -> Shopify checkout -> order history in a native mobile app
Operations
Seller connection, catalog sync, merchandising, search, customers, and order visibility across admin surfaces
Architecture
Flutter buyer app, Remix APIs, Shopify sales channel, MongoDB/Prisma data model, Typesense index, and EventBridge webhooks
Stack
FlutterRemixNext.jsShopifyPrismaMongoDBTypesenseStytch
Reflections
- The hard part was not a single screen - it was keeping buyer, seller, and admin surfaces aligned around the same catalog, cart, and order state.
- Using Shopify for cart and checkout kept payments and commerce primitives on a proven backbone while the marketplace layer handled discovery, merchandising, search, and operations.
Next step
Have a similar project?
If this looks close to the product work you need, book a short call and I will help scope the next step clearly.