Recommerce and Trade In Platform Problems: The 7 That Cost Real Money and How to Avoid Them

Why does the one SKU per item workaround happen so often?

Every recommerce build starts inside a commerce platform that treats a SKU as a template and inventory as a count. There are forty seven of size medium in black, they are interchangeable, and buying one is identical to buying another. A used item breaks that completely: it has its own photographs, its own condition, its own repair history and its own price, and there is exactly one of it.

The workaround everybody reaches for is minting a new SKU for every unit. It is fast, it uses the platform you already have, and it works for the first few hundred items. Then the catalogue holds tens of thousands of single unit products, search returns noise, merchandising rules that assume a product family stop making sense, and reporting becomes meaningless because every product has a lifetime sales quantity of one. Teams usually discover this in the same quarter the programme starts working, which is the worst possible timing.

The fix is a serialised item model sitting alongside the product catalogue rather than inside it. The product remains the template that carries style, brand, size and original specification. The item is a separate object with its own condition, media, work order, cost stack and ownership history, linked to the template. Storefront listings are generated from items, and when an item sells the listing disappears rather than decrementing. Decide this in week one, because retrofitting it after forty thousand single unit SKUs exist is a migration project on top of a build.

What goes wrong when pilot and legacy data is migrated?

Most brands arrive at a build having already run a pilot, usually on Trove, Recurate or Archive, or on a spreadsheet beside a manual bench process. That pilot history is the most valuable input the new system will ever receive, because resale pricing only works when it is derived from your own sell through rather than from a percentage rule. It is also the data that migrates worst.

Two things break. The first is grade mapping. The pilot used condition tiers defined by somebody else, often three or four broad bands, and your new rubric computes grades from attribute checks. Mapping old good onto new good is a guess, and if you feed those guessed grades into a pricing model you get prices derived from noise. The second is missing cost. Pilot records almost never carry refurbishment labour or parts against the item, so historical margin cannot be reconstructed, only historical revenue.

The fix is to migrate the history but mark its provenance. Legacy records carry a flag showing the grade was mapped rather than computed, and the pricing model weights them accordingly or excludes them from anything cost related. Keep the sell through data, since days to sell and realised price per style and size are genuinely useful even when the grade is approximate. And set the expectation with the commercial team that pricing derived purely from history becomes trustworthy after a few months of properly graded units, not on day one.

Why do the integrations that matter break after launch?

Four integrations carry a recommerce build and each fails in a way specific to used goods.

The commerce platform is first. Listing unique items into a storefront designed for templated products works during testing with fifty items and struggles at volume, usually on search indexing and on any merchandising rule that assumes a product family. Decide early whether resale lives on the parent storefront, on a separate site, or as a hybrid, because those are three different projects and a quote given before that decision is not a quote.

The warehouse system is second. It knows put away and pick. It has no concept of an item that must pass through cleaning, repair, re photography and quality control before it becomes sellable, so teams bolt refurbishment on as a status field and then cannot see where anything is.

The store credit and loyalty ledger is third, and it fails politically rather than technically. If resale credit lands in its own wallet rather than the balance customers already recognise, redemption falls and the programme's whole commercial case, which is credit spent in your channel on a larger basket, quietly disappears.

Carrier label generation is fourth, and it fails on cost rather than function. Prepaid inbound labels are free to issue and expensive to honour, so label spend has to be capped and attributed per customer from launch rather than reviewed later.

What happens when refurbishment and credit controls are not covered?

The two gaps that hurt most are on the operations side, and both are usually deferred to phase two.

Refurbishment first. An arriving item may need a wash, a replaced button and a re photograph. Those are three tasks at three stations with different costs and durations. Treated as a warehouse status, none of that is measured, so acquisition credit is the only cost you can see per item and it is typically the smaller half. Once refurbishment becomes a work order with routed tasks, standard times, tracked parts consumption and a quality check gate, you get true cost per item: credit plus labour plus parts plus storage days. That number is what tells you one category is carrying the programme while another loses money on every unit accepted, and stopping the second is usually the single largest profit improvement available.

Store credit second. Credit is money, and issuing it programmatically invites testing at volume. The predictable patterns are bulk submissions of worthless items hoping intake is rushed, claiming a higher condition at submission and disputing the graded outcome, shipping an empty box against a generated label, and cycling the same unit back through a second account after it resells. None of that requires sophistication.

The controls are unglamorous. Issue credit on the graded outcome rather than the customer claim, with a visible appeal route so honest disputes have somewhere to go. Cap prepaid label cost per customer per period. Where the category has serial numbers or item identifiers, check them against previously accepted units. Require an authentication step before credit issues above a value threshold. All of these have to be automatic, because they are volume attacks and an attentive intake operator is not a control.

Should you build custom or configure what you already own?

If you are still proving that customers will send items back at all, do not build. Trove will run the whole operation including logistics, which is exactly what a pilot needs and removes the need to hire graders before you know the volume. Recurate is a reasonable route for testing peer to peer resale on your own domain, and Archive is credible brand resale infrastructure. All three get you live in weeks. Paying an operator to prove demand is far cheaper than building a platform for a programme nobody uses, and we would say so before quoting.

Configuring what you own is also the right answer when volume is low and the real complaint is manual admin. A structured intake form, a disciplined bench process and a spreadsheet genuinely works below a few hundred items a month.

Build when two or more of these hold. Volume has passed roughly 2,000 items a month and per item fees have become the largest line in the programme. Your grading rubric is genuinely brand specific and generic condition tiers are costing you margin on every unit. You want resale inventory and credit inside your own inventory and loyalty systems rather than a partner's. Refurbishment happens in your own facility and you cannot see its true cost. Or the resale data matters strategically, because knowing which of your styles hold value is a product design input you should not be renting.

How do hidden costs get into the quote?

Estimates move in the same places on almost every recommerce build.

• Category count. Each category needs its own grading rubric, and each rubric is a real working session with the people who know the product. Two categories is not twice one, but ten is not ten times one either, and quotes that ignore the count are guessing.
• Storefront approach. Integrating unique items into an existing commerce platform, running a separate resale site, and building a hybrid are three different projects. Decide before you ask for a number.
• Photography. Consistent images at volume is a physical process problem before it is a software one, involving lighting, backgrounds, fixed angles and a station that keeps up with intake.
• Authentication. In categories where counterfeits circulate this is expertise capture rather than software, and it should be a separate line with your own specialists involved.
• Multi region takeback. Returns logistics and the customs treatment of used goods differ by country, so the second region is rarely a configuration change.
• Parts inventory. Replacement zips, buttons and batteries are stock that has to be ordered, counted and consumed against work orders, which is a small system in its own right.

What separates a build that works from one that fails here?

The builds that work model the item as a first class object on day one, compute grades from attribute checks rather than asking a person to choose a tier, route refurbishment as work orders so cost attaches to the unit, and close the loop by comparing every grade against what the item eventually sold for. That last one is the habit that keeps the programme honest, because it produces a per grader accuracy record and stops the rubric decaying quietly over two quarters.

The builds that fail treat grading as a form field and refurbishment as a status. Within a year they can report units accepted, units listed and revenue, and cannot answer the only question that matters, which is whether accepting a given category makes money. They also tend to place resale credit in a separate wallet, which reduces redemption and removes the commercial argument the programme was funded on.

Two tests before signing. Ask a developer to model the item on a whiteboard, and watch whether they separate the product template from the individual unit with its own condition, media, work order, cost stack and ownership history. Then ask how grading consistency will be measured after launch, and listen for a feedback loop tied to realised resale outcomes rather than a spot audit. Settle ownership of the code, the rubrics, the pricing models and the resale sales history before kickoff, because that history is the asset the whole programme compounds on.