Building a Cross-Listing Platform

Cross-listing is the bread and butter of reselling. If you sell on eBay, you want your items on Poshmark, Mercari, and Facebook Marketplace too. More eyeballs, more sales. But managing listings across four or five platforms manually is tedious and error-prone.

That's the problem SellTheFlip solves. I built it from scratch — product design, architecture, frontend, backend, and deployment — as a solo engineer.

The Problem

Resellers spend hours copying and pasting titles, descriptions, and photos between platforms. Each marketplace has different category taxonomies, required fields, and image specifications. A single item might take 15-20 minutes to list across three platforms. For someone managing hundreds of items, that's a full-time job just to keep listings in sync.

Architecture Decisions

I chose Next.js with a PostgreSQL backend (via Prisma) for a few reasons:

• Server-side rendering for the dashboard gave me good SEO for the marketing pages and fast initial loads for the app itself.
• API routes kept the backend co-located with the frontend, simplifying deployment.
• Prisma's type-safe queries caught data model issues at compile time instead of runtime.

The core challenge was building a unified product data model. Each marketplace represents items differently — eBay uses item specifics, Poshmark has fixed categories, Mercari uses a condition scale. I designed a canonical product schema that maps to each platform's requirements through a transform layer.

interface Product {
  id: string;
  title: string;
  description: string;
  price: number;
  images: string[];
  category: CanonicalCategory;
  attributes: Record<string, string>;
}

interface ListingTarget {
  platform: Platform;
  transform: (product: Product) => PlatformListing;
  validate: (listing: PlatformListing) => ValidationResult;
}

Handling Marketplace APIs

Every marketplace API has quirks. eBay's API is well-documented but verbose. Poshmark doesn't have a public API at all — I had to reverse-engineer their endpoints. Mercari's rate limits are aggressive.

I built an abstraction layer that normalizes these differences:

• A queue system handles bulk operations with per-platform rate limiting
• Retry logic with exponential backoff handles transient failures
• A webhook-like polling system monitors listing status across platforms

What I Learned

Building a product solo forces clarity. There's no one to delegate the hard parts to, so every architectural decision has to be pragmatic. I optimized for:

1. Speed of iteration over architectural purity
2. User-visible progress over backend elegance
3. Reliability over feature count

The most important lesson: ship the smallest thing that solves a real problem, then iterate based on what actual users tell you. The first version of SellTheFlip listed to two platforms. That was enough to validate the idea.