DEV Community: Saloni Jain

The Double-Sell Problem: Keeping One Item in Sync Across Two Marketplaces

Saloni Jain — Wed, 04 Nov 2026 16:27:59 +0000

Ask a seller who lists on more than one marketplace what keeps them up at night, and you'll hear the same answer: selling the same item twice.

A limited-edition pair of sneakers, the only one the seller has, is listed on eBay and on a second marketplace. Two buyers check out within a minute of each other. One gets the sneakers. The other gets a cancellation, and the seller gets a defect on their account.

From the outside, the fix looks trivial: when it sells in one place, remove it from the other. In practice, that one sentence hides most of the classic problems of distributed systems: unreliable delivery, ordering, retries, concurrency and drift. This is a walkthrough of why cross-listing breaks, and the patterns that make it reliable.

Why sellers cross-list in the first place

Selling on more than one channel has become normal for regular sellers: a large marketplace for reach, plus another marketplace or the seller's own store. This piece is about the plumbing underneath that setup.

The moment one physical item is visible in two places, you have two systems that both believe they can sell it. Everything else follows from that.

Problem 1: there is no shared source of truth

Each marketplace keeps its own idea of how many units you have. On eBay's Inventory API, quantity lives on an inventory item identified by a seller-defined SKU, and is referenced again by each offer that turns that item into a live listing. A second marketplace has its own record. Neither knows about the other.

The first design decision, and the most important one, is to stop treating any marketplace as the source of truth. The seller's own inventory record, keyed by SKU, is the master. Marketplaces are projections of it.

// The master record. Marketplaces are views of this, not the other way round.
const item = {
  sku: "SNK-0193",
  available: 1,
  version: 7,           // increments on every change
  channels: {
    ebay:   { listingId: "…", syncedVersion: 7 },
    second: { listingId: "…", syncedVersion: 6 }  // behind: needs a push
  }
};

That syncedVersion field does a lot of work later. It lets you see, at any moment, which channel is out of date.

Problem 2: "it sold" arrives late, twice, or not at all

The fastest way to learn about a sale is a webhook: the marketplace calls your endpoint when an order is created. eBay offers this through its Notification API, with subscriptions to event topics and public keys to verify that a message really came from eBay. Shopify offers webhooks too, signed with an X-Shopify-Hmac-Sha256 header.

Webhooks are fast, but they are not a guarantee. Shopify's own webhook documentation is refreshingly blunt about it:

delivery "isn't always guaranteed," and your app can miss events through handler failures or downtime;
Shopify "doesn't guarantee ordering within a topic, or across different topics for the same resource";
duplicate deliveries happen, which is why each one carries an X-Shopify-Webhook-Id you can use to ignore repeats.

So a sync engine that relies only on webhooks will, eventually, miss a sale. And a missed sale on one channel is exactly how the double-sell happens.

Pattern 1: verify, deduplicate, then act

Every incoming event goes through the same three steps before it touches inventory:

async function handleOrderWebhook(req) {
  if (!verifySignature(req)) return reject(401);      // 1. is it genuine?

  const eventId = req.headers["x-shopify-webhook-id"];
  if (await seen(eventId)) return ok();               // 2. have we processed it?

  await applySale(req.body);                          // 3. act exactly once
  await markSeen(eventId);
  return ok();
}

Step 2 is what makes the handler idempotent: processing the same event twice has the same effect as processing it once. It's the same idea Stripe applies to API calls with idempotency keys, so a retried request never creates a second charge.

In practice, markSeen and applySale should commit in the same database transaction. If the process crashes between them, you either lose the sale or apply it twice on retry.

Pattern 2: decrement first, then delist everywhere else

When a sale is confirmed on one channel, the order of operations matters:

Decrement the master record in a single atomic update, guarded by the current version.
Queue a delist (or quantity update) for every other channel that still shows the item.
Push those updates with retries, marking each channel's syncedVersion when it succeeds.

UPDATE inventory
SET available = available - 1, version = version + 1
WHERE sku = 'SNK-0193' AND available > 0 AND version = 7;
-- 0 rows updated means someone else got there first.

The available > 0 guard and the version check turn a race into a clean failure. It's the same principle behind flash-sale systems that don't oversell, except here the competing buyers arrive through different companies' systems instead of one. If two sales arrive at once, only one decrement succeeds. The other is detected immediately, so the seller can cancel and refund it at once rather than discovering the problem when they go to pack the item.

Step 2 is a classic dual-write problem: you need to update your database and reliably trigger calls to external APIs. Writing the "delist this on channel X" jobs into an outbox table in the same transaction, then publishing them separately, avoids losing them if the process dies mid-way. This is the classic use case for the transactional outbox pattern.

Pattern 3: reconcile, because webhooks will miss things

Even with perfect handlers, you'll miss events: deploys, outages, expired tokens, a marketplace having a bad day. Shopify's documentation says it directly: your app "shouldn't rely on receiving data from Shopify webhooks," and it recommends reconciliation jobs that periodically fetch data updated since the last run.

A reconciliation loop is the safety net under everything else:

// Runs every few minutes, per channel.
async function reconcile(channel) {
  const since = await lastReconciledAt(channel);
  const orders = await channel.fetchOrdersUpdatedSince(since);
  for (const order of orders) {
    await applySaleIfNew(order);   // same idempotent path as webhooks
  }
  await checkDrift(channel);       // compare channel quantities to master
  await setLastReconciledAt(channel, now());
}

Two details make this work:

Reuse the idempotent sale handler. A sale found by reconciliation goes through exactly the same code as a webhook, so it doesn't matter which one sees it first.
Check drift, not just orders. Compare each channel's listed quantity against the master record. If a listing shows 1 and the master says 0, push a correction. That catches the case where a delist call quietly failed.

Pattern 4: close the gap at checkout, where the platform allows it

Even a fast pipeline leaves a window of seconds between a sale on one channel and a delist on the other. For one-of-a-kind items, some platforms let you close that window at checkout instead.

eBay's Inventory API documentation describes a Real-time Inventory Check, where "eBay will make a call to this endpoint at checkout" to confirm enough quantity exists before the purchase completes. If your master record says the item is gone, the second buyer is stopped before paying, not after.

Not every marketplace offers a hook like this, but where one exists, it's the strongest protection against a double-sell, because it moves the check from after the sale to during it.

Problem 3: the same item isn't the same data

Inventory is only half the job. Getting an item listed on a second channel at all means mapping one data model onto another:

Categories don't line up. One marketplace's "Cameras & Photo > Film Cameras" is another's "Electronics > Cameras". You need a category map, and a fallback for items that don't fit.
Attributes differ. eBay uses item specifics; other platforms use their own fields, or none. Brand, model, size and condition need mapping, and condition labels rarely match one to one.
Editing rules differ. eBay notes that listings created through its Inventory API can't then be edited in Seller Hub or other listing tools; revisions have to go through the API. If a seller edits by hand somewhere else, your system and the marketplace disagree.

This is why import tools matter so much to sellers. A marketplace that can take existing listings from another platform does this mapping once, instead of making the seller retype every item. TrueGether, one of the eBay alternatives built for independent sellers, imports listings from eBay and Shopify, and the hard part of any importer like that isn't fetching the data. It's deciding what to do with the fields that don't map cleanly.

A checklist for anyone building cross-channel sync

Own the source of truth. Keep a master inventory record keyed by SKU, with a version number. Marketplaces are projections.
Treat every event as untrusted and repeatable. Verify signatures, deduplicate by event ID, and make the handler idempotent.
Decrement atomically. Guard updates with available > 0 and a version check so races fail cleanly.
Don't lose side effects. Use an outbox for delist and update calls to other channels.
Reconcile on a schedule. Assume webhooks will be missed, and compare quantities across channels to catch drift.
Use checkout-time checks where they exist. They're the only way to stop a double-sell before the buyer pays.
Map data deliberately. Categories, attributes and condition labels need explicit rules and a fallback.

The takeaway

Cross-listing looks like a sales tactic, but it's really a consistency problem: one physical object, several systems that each think they can sell it, and networks that don't promise delivery or order. The sellers who get it right, or the tools they rely on, aren't the ones with the fastest webhooks. They're the ones who assume events will be late, duplicated or missing, and design for that from the start.

If you're building or choosing a cross-listing setup, test it against the seven-point checklist above before trusting it with a one-of-a-kind item.

FAQ

Why do cross-listed items sometimes sell twice?

Because each marketplace keeps its own stock count, and the "item sold" signal from one channel can arrive late, twice or not at all. Until the other listing is updated, both channels still show the item as available.

Are webhooks enough to keep inventory in sync?

No. Webhooks are fast but not guaranteed, and Shopify's documentation recommends reconciliation jobs alongside them. Use webhooks for speed and a scheduled reconciliation for correctness.

What does idempotent mean for a webhook handler?

Processing the same event twice has the same effect as processing it once. In practice: deduplicate by event ID and record the event in the same transaction that applies the sale.

Can I move my eBay listings to another marketplace without retyping them?

Often, yes. Some marketplaces can import existing listings directly or accept an inventory file. TrueGether, for example, imports listings from eBay and Shopify and accepts inventory file uploads. Whichever platform you use, check the imported categories, item specifics and condition labels before going live, because those are the fields that rarely map one to one.

Platform behaviour described here comes from eBay's Inventory and Notification API documentation and Shopify's webhook documentation, checked October 2026. APIs change, so always confirm against current docs before building.

Moving Marketplace Listing Pages From Microdata to JSON-LD

Saloni Jain — Fri, 30 Oct 2026 15:21:30 +0000

If your product pages were built a few years ago, there's a good chance their structured data is written in Microdata: itemscope, itemtype and itemprop attributes spread through the HTML. It works, but it's tied to the template. Every time someone redesigns a component, the markup can quietly break.

JSON-LD keeps the same information in one <script type="application/ld+json"> block, separate from the layout. Google supports all three formats (JSON-LD, Microdata and RDFa) and says they're equally fine when the markup is valid, but it recommends JSON-LD where your setup allows, as the easiest to implement and maintain at scale and the least prone to errors.

On a marketplace, where listing pages are generated from seller data you don't fully control, that maintainability matters even more. Here's how we're approaching the move.

1. Before: what Microdata looks like on a listing page

A typical Microdata listing mixes the markup into the visible HTML:

<div itemscope itemtype="https://schema.org/Product">
  <h1 itemprop="name">Canon EF 50mm f/1.8 STM Lens</h1>
  <img itemprop="image" src="/img/listing-123.jpg" alt="Canon EF 50mm lens">
  <div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
    <span itemprop="priceCurrency" content="USD">$</span>
    <span itemprop="price" content="89.00">89.00</span>
    <link itemprop="availability" href="https://schema.org/InStock">
    <link itemprop="itemCondition" href="https://schema.org/NewCondition">
  </div>
</div>

It's valid, but the structured data now depends on the exact nesting of divs. Move the price into a different component during a redesign, and price can end up outside its Offer without anyone noticing.

2. After: the same data as JSON-LD

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Canon EF 50mm f/1.8 STM Lens",
  "image": ["https://www.example.com/img/listing-123.jpg"],
  "description": "Canon EF 50mm f/1.8 STM lens, new in box.",
  "brand": { "@type": "Brand", "name": "Canon" },
  "offers": {
    "@type": "Offer",
    "url": "https://www.example.com/listing/123",
    "price": "89.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "seller": { "@type": "Person", "name": "example_seller" }
  }
}
</script>

The page's HTML can now change freely, as long as the JSON-LD still describes what the buyer sees.

3. Generate it on the server from your listing model

Hand-writing JSON inside a template is how bugs creep back in. Build it from the same listing object that renders the page, and serialize it with a real JSON library.

![Five steps to generate JSON-LD for a listing page: listing model, map values, serialize, escape, embed and test]

In a Java stack, for example, with Jackson:

Map<String, Object> offer = new LinkedHashMap<>();
offer.put("@type", "Offer");
offer.put("url", listing.getCanonicalUrl());
offer.put("price", listing.getPrice().setScale(2, RoundingMode.HALF_UP).toPlainString());
offer.put("priceCurrency", "USD");
offer.put("availability", listing.isSold()
        ? "https://schema.org/SoldOut"
        : "https://schema.org/InStock");
offer.put("itemCondition", conditionUrl(listing.getCondition()));
offer.put("seller", Map.of("@type", "Person", "name", listing.getSellerName()));

Map<String, Object> product = new LinkedHashMap<>();
product.put("@context", "https://schema.org");
product.put("@type", "Product");
product.put("name", listing.getTitle());
product.put("image", listing.getImageUrls());
product.put("description", listing.getShortDescription());
product.put("offers", offer);

String json = objectMapper.writeValueAsString(product);

Two details in that snippet are there on purpose:

Price as a plain decimal string, with no currency symbol or thousands separator, and the currency in priceCurrency as an ISO code such as USD.
Availability follows the listing's real state. On a marketplace, listings sell out constantly. Marking a sold item InStock sends buyers to a dead end and breaks the rule that markup must match the page.

4. Escape seller-written text before it goes into a script tag

This one is specific to marketplaces and other user-generated content. Listing titles and descriptions are written by sellers. If a title ever contains </script>, unescaped JSON-LD can close your script tag early, which breaks the page at best and opens an injection hole at worst.

A JSON library escapes quotes and backslashes, but it doesn't make text safe inside HTML. Escape <, > and & as Unicode escapes after serializing:

String safeJson = json
        .replace("<", "\\u003c")
        .replace(">", "\\u003e")
        .replace("&", "\\u0026");

The output is still valid JSON, and parsers read it exactly as before.

5. Map conditions explicitly

Sellers describe condition in their own words; schema.org has a fixed list. Use an explicit mapping rather than passing seller text through:

static String conditionUrl(Condition c) {
    switch (c) {
        case NEW:         return "https://schema.org/NewCondition";
        case REFURBISHED: return "https://schema.org/RefurbishedCondition";
        case USED:        return "https://schema.org/UsedCondition";
        default:          return null; // omit rather than guess
    }
}

If you can't map a value confidently, leave the property out. A wrong condition is worse than a missing one.

6. Name the actual seller, and check what you're eligible for

On a marketplace, the person selling the item usually isn't the marketplace itself. Schema.org's Offer has a seller property, so the markup can say who the seller is.

This also matters for what Google can show. Google's merchant listing documentation says the "merchant has to be the seller of the product in order to be eligible for merchant listing experiences." Read that section carefully against your own setup before expecting merchant listing features. Product markup is still useful for describing the page accurately, but don't assume every rich result applies to a marketplace listing.

7. Remove the Microdata when the JSON-LD goes live

Running both formats for the same product on one page makes it easy for the two to disagree, especially on price and availability. Switch one template at a time, and remove the old itemprop attributes in the same release.

8. Validate before and after

Rich Results Test on a sample of listing URLs, including sold, used and multi-image listings, not just the tidy ones.
URL Inspection in Search Console to see the page as Google renders it.
Search Console's structured data reports after release, to catch errors that only show up across thousands of pages.

Keep in mind that valid structured data makes a page eligible for rich results; it doesn't guarantee them.

Checklist

Generate JSON-LD on the server from the listing model, with a JSON library.
Price as a plain decimal string, currency as an ISO code.
Availability and condition reflect the real listing; omit values you can't map.
Escape <, > and & in the serialized JSON.
Use seller for the actual seller, and check merchant listing eligibility rules.
Remove the old Microdata in the same release.
Test sold, used and edge-case listings, then watch Search Console.

Moving to JSON-LD isn't a ranking trick. It's a way to describe every listing accurately and keep it accurate as the site changes, which matters more the more listings and sellers you have.

FAQ

Is JSON-LD better than Microdata for SEO?

Google treats all three formats as equally valid when the markup is correct. It recommends JSON-LD because it's easier to implement and maintain at scale and less prone to errors.

Can I use JSON-LD and Microdata on the same page?

You can, but describing the same product twice makes it easy for the two to disagree. When migrating, remove the Microdata in the same release that adds the JSON-LD.

What should availability be when a listing has sold?

Use a value that matches the page, such as https://schema.org/SoldOut, rather than leaving InStock in place.

Disclosure: written by the TrueGether team. TrueGether is one of the eBay alternatives built for independent sellers, with listing pages across categories from electronics to collectibles.

Rewriting a High-Traffic Page Without Breaking It: Notes from the Listing Details Migration

Saloni Jain — Thu, 08 Oct 2026 14:47:53 +0000

TrueGether is an eBay alternative built around a zero-fee model for sellers. This post's about the Listing Details page: the single page every buyer lands on before deciding whether to buy something on TrueGether, and the one we were most nervous about touching.

We rebuilt it in React, Vite, TypeScript, and Tailwind. The stack decision wasn't the hard part. What actually took the time was everything the old page was quietly doing that nobody had written down anywhere.

What the old page was actually carrying

The pattern is probably familiar to anyone who's rebuilt a page that's been patched for years: small fixes accumulate into undocumented behavior. Small fixes can accumulate into undocumented behavior: a spacing rule that only matters for one product category, or logic that was added for an old edge case and never removed because nobody was sure what would break.

Why Vite mattered more than we expected

The concrete effect was on how willing people were to iterate during review. A slow feedback loop doesn't just cost time, it changes behavior — people stop trying small improvements when every attempt costs thirty seconds of waiting.

TypeScript found problems that weren't type problems

This was the real surprise. Adding types to a page handling prices, variants, inventory, and seller data didn't just catch mismatches — it forced us to actually agree on what shape that data was supposed to be. The important part wasn't any single mismatch. It was that the type system forced us to make assumptions explicit instead of letting them remain implicit. The type system didn't cause those problems. It just made them impossible to keep ignoring.

The Tailwind migration cost was about unlearning, not learning

The class-name syntax isn't the hard part of adopting Tailwind. The hard part is years of CSS instinct — reaching for a new stylesheet rule instead of composing utility classes — not disappearing just because the tooling changed.

What we'd do differently

The risk in a rewrite like this was never really the new code — it was the undocumented behavior sitting in the old code that nobody had mapped out. That's the main lesson we're carrying into the next piece of TrueGether's infrastructure we touch: map it before you migrate it, not during.

Lessons From Building a Zero-Fee eBay Alternative

Saloni Jain — Fri, 25 Sep 2026 15:02:21 +0000

I work on TrueGether, a marketplace that's been running since 2012 where you can sell an item with no commission taken out — no listing fee either, unlike most of the platforms sellers are used to. I didn't build the business model, but I've spent a lot of time on the engineering side of what that pricing model actually forces you to get right, and I wanted to write down what that's taught me, mistakes included.

"Zero fee" is a product constraint, not just a pricing page

The first thing that becomes obvious once "no commission" is the pitch: you can't paper over friction with money. A marketplace that charges 10-13% per sale can afford a clunky onboarding flow, because the revenue is already flowing. We don't have that cushion, so every point of friction in listing, searching, and checkout has to earn its keep on its own. That reframes a lot of otherwise "nice to have" engineering work as actually load-bearing for the business.

The clearest example: a huge number of sellers who'd consider a second marketplace already have a working catalog somewhere else — usually eBay or Shopify. Asking them to manually re-list everything is the single biggest thing standing between "interested" and "actually selling." So instead of just building a listing form and hoping, we built import tooling that pulls an existing eBay or Shopify catalog in directly. It's not glamorous work, but it probably did more for adoption than any feature we shipped that quarter.

Search gets weird when your catalog is everything

TrueGether spans a genuinely wide catalog — electronics, jewelry, collectibles, home goods, sporting goods, and a couple dozen categories beyond that. That's great for being a real "one place to list" marketplace, but it's rough on search relevance. A query like "case" means something completely different in Electronics (phone case) than in Musical Instruments (guitar case) than in Collectibles (display case). Generic relevance tuning that works for a single-category shop falls apart fast at that breadth.

We run Solr for search, and most of the actual engineering effort there isn't indexing — it's building enough category-aware signal into ranking that a broad, ambiguous query still surfaces the right cluster of results instead of a blend of unrelated ones. It's the kind of problem that looks small until you're staring at a search log full of near-misses.

Caching a marketplace is not caching a blog

Varnish sits in front of a lot of our read traffic, and for a mostly-static site that's a solved problem. A marketplace is not mostly static — prices change, items sell out, sellers edit listings — so overly aggressive caching means showing a buyer something that's no longer true, and overly cautious caching means your origin gets hammered on every category page. We ended up spending more time on invalidation strategy (what has to bust the cache immediately vs. what can lag by a few minutes) than on the caching layer itself, which was the opposite of what I expected going in.

Rewrite less than you think you need to

Some of the frontend is still JSP. Some of it — the listing details page, most recently — has been rebuilt in React, TypeScript, and Tailwind. I used to be a "just rewrite it properly" person, and working on a live marketplace cured me of that. You can't take checkout offline for a quarter to do a clean rewrite, so the actual skill is figuring out which single page or flow to modernize next, shipping it behind the old one, and letting the two coexist without users noticing the seam. It's slower and less satisfying than a fresh start, but it's the only version of "modernize the stack" that doesn't put revenue at risk.

What I'd tell someone building a marketplace from scratch

None of this is exotic technology — Solr, HBase, Varnish, Docker, a slow React migration. The lessons weren't really about picking the right tools, they were about which problems actually matter when your pricing model removes the usual safety net. Building a real eBay alternative — not just a cheaper clone with the same fee structure — turned out to be less about the pricing page and more about all of the above. If you're not charging fees, your infrastructure has to work harder to justify why anyone stays, because you can't buy their patience with a good deal — the deal is the default state.

If you want to see where all of this actually landed, the same import-and-list flow I described above kicks in the moment you become an online seller there — it's running in production, not just on a roadmap slide.

Happy to go deeper on any of this in the comments — search relevance and cache invalidation are the two I'd genuinely enjoy nerding out about further.

Why We Built One-Click Catalog Import for Sellers Switching Marketplaces

Saloni Jain — Tue, 18 Aug 2026 11:54:32 +0000

Every marketplace pitch to sellers eventually runs into the same wall: "okay, but I have 400 listings on eBay already."

That single sentence kills more platform switches than pricing, trust, or features combined. Asking someone to manually recreate hundreds of titles, photos, prices, and descriptions isn't a small ask — it's a weekend of unpaid work before they've sold a single item. So when we were building TrueGether, a marketplace positioned as a practical eBay alternative for people who want to start selling online, new or used, without giving up a cut of every sale, we knew the "empty store" problem would matter more than almost anything else in the product.

The real friction isn't fees, it's the migration

We'd assumed price would be the deciding factor for sellers. It wasn't. In early conversations, the objection that came up again and again was some version of: "I believe you're cheaper, but I'm not starting from zero." Sellers who'd spent years building out a catalog on eBay or a Shopify store weren't going to abandon that catalog just to test a new platform, no matter how good the pitch to sell online without fees sounded on paper.

That reframed the problem. It wasn't "how do we convince sellers to switch," it was "how do we make switching cost nothing."

What we built: listings that carry over intact

We ended up building an import path that pulls existing listings in directly from eBay and Shopify — titles, prices, photos, quantities, and descriptions come across instead of needing to be rebuilt by hand. The seller reviews and confirms rather than starting from a blank form.

The unglamorous part of this work was category mapping. eBay and Shopify each have their own sprawling, inconsistent taxonomy, and none of it lines up cleanly with a simpler category structure. A listing sitting three levels deep in eBay's antiques tree doesn't have an obvious 1:1 home — we had to decide where the mapping should be strict versus where it made more sense to fall back to a broader parent category and let the seller fine-tune from there.

Photos were the other place small decisions mattered. Keeping image order and primary-photo selection intact sounds trivial until you're moving hundreds of listings at once and one broken mapping means every photo in a shop is off by one.

Reputation had to move too, not just inventory

Listings were only half the migration problem. A seller with 1,200 reviews and a 4.9 rating on eBay isn't just losing a catalog by switching platforms — they're losing years of earned trust and starting over as an anonymous new account. For anyone who's spent years building a track record, that's a bigger deterrent than rebuilding listings ever was.

So the import path also carries over the seller's existing ratings and reviews — not just an aggregate score, but the actual reviews customers left. A buyer looking at a "new" seller on TrueGether can still see the reputation that seller earned somewhere else, instead of everyone starting from a blank slate regardless of track record.

This ended up being the harder design problem of the two. Listings are static data — copy the fields, map the categories, done. Reputation is trust, and trust only means something if it's clearly attributed and verifiably tied to the account that earned it. Getting that balance right mattered more than getting the import mechanically working.

Why this mattered more than a fee comparison

None of this shows up in a "compare our fees to eBay's fees" pitch, but it's the actual product of taking migration seriously — not just cheaper, but nothing lost in the switch, neither catalog nor reputation. A cheaper platform that still costs someone a weekend of manual work and a blank reputation isn't actually cheaper — it just moves the cost from money to time and trust.

If you're building anything that asks users to migrate from an incumbent platform, the lesson generalized further than we expected: the technical lift of a clean, trust-preserving import isn't a nice-to-have feature, it's often the actual decision that determines whether anyone tries you at all.

If you're weighing TrueGether as your next storefront or just exploring it as a side hustle selling platform, you can see how listings and reviews come across on the seller signup page.

FAQ

1. What exactly gets imported from an eBay or Shopify store?
Titles, prices, photos, quantities, and descriptions carry over, along with category mapping. The seller reviews everything before it goes live rather than it publishing automatically.

2. Do reviews transfer too, or just listings?
Both. Along with the catalog, existing ratings and reviews carry over — not just an aggregate score, but the actual reviews customers left — so a seller's track record isn't reset by switching platforms.

3. Which platforms can sellers import from right now?
eBay and Shopify are supported today.

4. Is there a cost to use the import tool?
No — it's part of the same zero-fee model as the rest of the platform, so there's no separate charge to bring a catalog or reputation over.

Designing a Category Taxonomy That Doesn't Collapse Under Its Own Weight

Saloni Jain — Mon, 27 Jul 2026 13:07:21 +0000

Every e-commerce or content platform eventually hits the same wall: the category tree that made sense with 200 items turns into an unmanageable mess at 200,000. A few of the actual design problems, and what tends to work:

Flat categories don't scale, but neither does infinite nesting. A single flat list of 'Electronics, Clothing, Home Goods' works fine at small scale and becomes useless once you have thousands of items per category — nobody can browse 40,000 'Electronics' listings. But going the other direction and nesting 6 levels deep (Electronics > Audio > Headphones > Wireless > Over-Ear > Noise Cancelling) creates a different problem: sellers guess wrong about where their item belongs, and half your inventory ends up misfiled.

Items rarely fit exactly one category. A wireless speaker with Bluetooth and a built-in flashlight is legitimately both 'Audio' and 'Outdoor Gear.' Most systems force a single primary category and treat everything else as a tag, but that means your category-page filtering logic and your tag-based search logic need to actually agree with each other, which is harder than it sounds once both systems evolve independently — general marketplaces spanning categories from electronics to home goods run into this constantly.

Category taxonomy is a data migration problem disguised as a UX problem. The moment you need to split 'Home & Garden' into 'Home Decor' and 'Garden & Outdoor' because one category got too large, every existing listing, every saved search, every analytics dashboard built around the old taxonomy breaks or silently miscounts. Versioning your taxonomy (so you can query 'what did this look like as of date X') ends up mattering a lot more than it seems like it should at design time.

Attribute-based filtering is often a better mental model than category depth. Instead of drilling deeper into subcategories, letting users filter by attributes (size, condition, brand, color) within a shallower category tree tends to actually match how people search, and it scales better as inventory grows, since you're adding filterable fields instead of restructuring the whole tree.

This is the kind of problem that looks trivial in a database schema diagram and turns into a genuine architecture decision once real inventory volume hits it — I've seen this come up in general marketplaces (TrueGether, an alternative to eBay, is one example of a platform spanning electronics-to-home-goods categories that has to solve this) and in any CMS with more than a couple hundred content types.

Curious how others have handled the single-vs-multi-category problem specifically — forcing one primary category plus tags, or building genuine multi-category membership from the start?