DEV Community: Saloni Jain

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?