Moonshine Art Marketplace Case Study

Public, sanitized architecture case study for a cross-platform art marketplace built around mobile commerce, seller onboarding, checkout, print fulfillment, moderation, compliance, and support workflows.

This repository intentionally does not contain private application source code, credentials, customer data, vendor account details, or unreleased business material. It is a portfolio artifact that documents the implementation shape and engineering decisions in a safe public form.

Role

Implementation and integration owner across the product foundation:

• Cross-platform app architecture
• Firebase data model and security boundaries
• Cloud Run API services
• Stripe checkout and Stripe Connect seller onboarding
• Print fulfillment adapter design
• Moderation, complaint, and compliance workflows
• Deployment and support handoff documentation

System Scope

The marketplace was organized as a monorepo with separate surfaces for the customer app, marketing site, backend services, moderation automation, and infrastructure.

Core surfaces:

• app/: Flutter client for browsing, accounts, checkout entry points, and marketplace UX.
• marketing/: Next.js static marketing site.
• backend/stripe-webhook/: Cloud Run API for checkout, Stripe Connect, webhooks, signup intent handling, and print proxying.
• backend/print-ship-adapter/: Cloud Run API boundary for Gelato catalog, quote, submission, preview, and webhook handling.
• backend/moderation-functions/: Firebase Functions v2 for moderation automation, compliance retention, notifications, signup blocking, and admin/support writes.
• infra/: Terraform-managed Google Cloud/Firebase resources and deployment configuration.

Architecture

Primary workflows:

• Seller onboarding: account setup, Stripe Connect onboarding, KYC state, marketplace profile readiness, and jurisdiction-specific disclosure snapshots.
• Buyer checkout: cart/variant selection, checkout session creation, Stripe webhook reconciliation, fulfillment handoff, and order state updates.
• Print fulfillment: quote, catalog, preview, order submission, webhook reconciliation, and supportable retry boundaries.
• Moderation and compliance: complaints, queueing, enforcement logs, disclosure requests, compliance archives, and support notifications.
• Operations: audit logs, support/contact threads, status checks, deployment separation, and admin-only writes.

Representative Data Model

Firestore collections were designed around operational boundaries rather than one large document shape:

• artists, users
• posts, variants
• orders, complaints, moderationQueue
• disclosureRequests, contactThreads, enforcementLogs
• complianceReports, complianceArchives
• campaigns, placements, notifications
• affiliateCodes, referralLinks, referralEvents
• signupIntents, config, auditLogs

Engineering Emphasis

This work is presented as evidence of practical implementation skills:

• Designing supportable API boundaries between client, payments, print fulfillment, and Firebase state.
• Handling webhook-driven state transitions without relying on the client as the source of truth.
• Separating public read paths, admin writes, support writes, and automated moderation actions.
• Keeping deployment and operational ownership explicit enough for handoff.
• Documenting a private implementation in a form that can be discussed publicly.

See Also

• Architecture Notes
• Support Handoff Notes
• Resume Summary

Portfolio Case Study

This repository is part of Jaron Rosenau's implementation, developer-support, and integration engineering portfolio. The public case study summarizes the problem, delivery scope, architecture, and operational result.

• Case study: Moonshine Art marketplace implementation case study
• Full portfolio: Jaron Rosenau
• Summary: Flutter/Firebase marketplace architecture covering seller onboarding, checkout, fulfillment, moderation, compliance, and support workflows.