I built a Vestiaire Actor, but “scraper” might be the wrong headline
I built an Apify Actor for Vestiaire Collective and I’m stuck on the positioning.
The obvious label is “scraper”.
But the workflow I keep coming back to is resale comps.
If someone is researching a bag, watch, or pair of shoes, they usually don’t just need a table of listings. They need to compare:
- live listings vs sold items
- condition
- seller country
- price changes over repeat runs
- seller-level patterns
- duplicate-ish listing signals that deserve manual review
So I’m testing a different frame:
A first-pass comps layer for luxury resale, exported as CSV/JSON/API, before building any SaaS UI.
I’m testing the current version here: Vestiaire Collective Smart Scraper
I’m deliberately not claiming it detects authenticity, private sold prices, or whether a seller is safe. It works from public pages, and the duplicate/risk signals are only heuristics for review.
My positioning problem:
Who would you lead with first?
- resellers looking for sourcing leads
- sellers pricing items from sold comps
- data teams wanting a Vestiaire API/export
- researchers tracking resale prices over time
- non-technical operators who would need a SaaS UI
My instinct is #2 or #3, because they feel more repeatable than “find deals”.
If you had to write the landing page headline, would you call this a scraper, sold comps tool, price tracker, seller intelligence layer, or data API?
I’d avoid leading with “scraper” — it describes the mechanism, not the value.
I’d lead with #3 first, because Apify users already want structured data/API/export, then use #2 as the main use case.
Headline idea:
“Vestiaire Collective comps API for resale pricing and market research.”
Keep “scraper” for SEO, but position it as a comps/data layer, not just a scraper.
That framing makes sense.
“Scraper” is accurate technically, but it puts the conversation in the wrong place. The buyer probably cares less about how the data is collected and more about getting clean comps they can export, compare, or plug into a workflow.
I like your split:
“Vestiaire Collective comps API for resale pricing and market research” is much clearer than “Vestiaire scraper.”
I’ll probably keep “scraper” in the Apify/SEO context, but make the main positioning about comps, pricing research, and market data.
On who to lead with: I'd go #2 (sellers pricing from sold comps). "Find deals" buyers churn once they've sourced, but someone listing items has the same pricing question every single week, that's the repeatable pain
memolife is pointing at. Price what removes a recurring decision.
One thing nobody's flagged though, and it matters more than the headline: the whole product sits on top of Vestiaire's pages, and most marketplaces put scraping squarely against their ToS and actively block it. You're
right to stay on public data and not claim authenticity, that's the smart line on claims. But the business risk isn't the claims, it's that your source can rate-limit you, change their markup, or send a C&D the week
you get traction. I run scrapers, and writing the scraper is the easy part, keeping it alive against a site that doesn't want you there is the actual job.
Not saying don't build it, the comps angle is genuinely useful. Just price and plan like the source can pull the rug, because eventually they try. That usually means owning the relationship with the buyer (the weekly
pricing habit) so you survive a data-source hiccup, instead of being a thin pipe on top of one site.
The real question isn't "scraper vs comps" — it's who you want typing the search that finds you. "Scraper" is what a developer Googles; "sold comps" is what a reseller Googles while holding a bag they can't price. Different buyers, different willingness to pay, and the noun just follows whichever you choose. And your own feature list already decides it: sold-vs-live, price changes across repeat runs, duplicate signals. That's not extraction, it's a pricing-confidence tool that happens to use public pages. Name it after the decision it removes, not the data it pulls.
Possibly.
The reason I'd still be careful is that I don't think the interesting question is what someone needs to see before caring.
I think there's a bigger decision sitting underneath that question.
That's not something I'd try to unpack properly in a thread.
If useful, drop your email and I'll put together the tighter version.
That makes sense.
I’d rather keep the first version public here, since the whole point is to pressure-test the positioning.
If you had to compress the bigger decision into one sentence, is it mainly:
Even a rough take would be useful.
Possibly, but that's exactly why I stopped short.
All four of those can end up looking important at the same time.
I wouldn't feel comfortable compressing it into a sentence because the value is in understanding which decision actually matters most.
That's not something I'd try to do properly in a thread.
If you change your mind, feel free to drop your email and I'll put together the tighter version.
Extra context: I’m leaning away from a SaaS UI until the workflow is clearer.
The current product is dataset/API-first. The proof artifact I’m considering next is a small sample run showing active vs sold rows for one narrow query, with condition and seller country filters.
Would that make the positioning easier to judge, or would you need to see a no-code UI before caring?