Case Study · 2026

Archive

Reducing friction across fragmented resale marketplaces with natural language search and AI-powered query translation.

Claude API React · TypeScript 15 platforms · 6 retailers Live demo
Contents 01 The Problem 02 Behavioral Insight 03 Defining the Product 04 Translation Layer 05 Constraints 06 Expanding the Product 07 Learnings

The Problem with Discovery

I wanted to stop wearing sneakers to every outing. New York's fashion-conscious crowds have a way of making you reconsider your wardrobe. Elevating my outfits led me naturally to the next step: a sleek black pair of leather boots, the kind you find in the archive resale market rather than a retail store.

So I started looking. And then I kept looking. And then I got frustrated.

Every online resale platform had its own logic. Grailed rewarded specific keywords. Depop prioritized recency over relevance. Yahoo Japan, which carries some of the rarest archive pieces in the world, required entirely different phrasing altogether. Each had its own filtering, its own price encoding, its own understanding of size.

The search for one pair of boots became twelve open tabs, six rewritten queries, six separate filter sessions. Fragmentation had turned discovery into a paralyzing and never-ending search.

The inconvenience wasn't the only thing that interested me. These platforms, I realized, had interfaces that poorly translated a user's wants.

They had enormous inventories and almost no ability to meet a user where their intent actually was. The search systems required me to study the platform and its quirks rather than simply express what I was looking for. The knowledge was mine. The friction was entirely theirs.

That disparity was the beginning of Archive.

Archive search input showing Black Leather Boots Size 43 EU

Archive's natural language input one query, fifteen platforms.

Behavioral Insight

The original idea was more ambitious. I wanted to build a true aggregation engine, something that scraped listings from every platform and centralized them into one searchable place. One interface, all the inventory, no tab switching.

I got far enough into it to understand why it didn't exist yet. The approach introduced inconsistent APIs, anti-scraping protections, constantly changing listing structures, pagination limitations, latency problems, duplicate inventory, and platform instability. The infrastructure cost of keeping it accurate would have been enormous, and the experience would have been fragile from day one.

But the more important realization wasn't technical. It was behavioral. These platforms weren't failing because they lacked inventory. They were failing because they assumed users would meet them halfway, learning each platform's logic, its keyword conventions, its filter structure, before getting to what they actually came for.

Users didn't need more listings in one place. They needed a shorter path from knowing what they wanted to finding where it existed.

Defining the Actual Product

Once I stopped thinking about Archive as an AI aggregator, the product became much clearer. Archive evolved into a search translation layer. Users describe what they want naturally, the system interprets their intent, queries get reformatted intelligently for different marketplaces, and users are routed directly into optimized search experiences.

Instead of replacing marketplaces, the product works with their existing ecosystems. That decision simplified everything significantly. Response times improved, infrastructure complexity dropped, reliability increased, and the product gained more flexibility across platforms with far less operational overhead.

People already trusted the marketplaces themselves. The frustrating part was navigating between them efficiently. Archive focused on removing that friction layer.

Original question

How do I replicate every marketplace in one place?

Better question

How do I reduce the cognitive friction between what a user wants and their next grail find?

Key insight

Users already trusted the marketplaces. The frustrating part was navigating between them. Replacing the platforms entirely was unfeasible and contradictory to our goal. We needed to remove the friction associated with running concurrent searches across all of them.

Archive results page showing resale and retail platform cards

One query surfaces results across 15 resale platforms and 6 luxury retailers simultaneously.

Designing the Search Translation Layer

The most interesting part of the project ended up being the translation problem itself. Natural language sounds simple conceptually, but fashion search behavior is surprisingly nuanced. Someone searching "black cropped Raf bomber" is communicating brand, silhouette, color, era-specific taste, likely sizing expectations, and stylistic intent all at once.

The challenge wasn't just parsing keywords. It was preserving intent while adapting searches to systems that all behaved differently. This led to experimentation around query decomposition, keyword prioritization, synonym handling, marketplace-specific formatting, and balancing specificity against recall. I found myself thinking less like an engineer and more like a user constantly negotiating with imperfect systems.

Grailed search with URL filters visible

Grailed size=footwear.10&price=0%3A400

Depop search with URL filters visible

Depop sizes=77.8-US&priceMax=400

The same search on two platforms. Different filter structures, different result ordering, different signals entirely. Multiply this across fifteen platforms and the friction becomes obvious.

Grailed
grailed.com/shop?query=black+leather+boots&size=footwear.10&price=0%3A400
size · price
Depop
depop.com/search/?q=black+leather+boots&sizes=77.8-US&priceMax=400
size · price

The goal was for Archive to generate both URLs automatically from a single natural language query, understanding distinctly Depop and Grailed's URL syntax rules. No manual filter toggling on either platform required.

Japanese platforms presented a uniquely complex translation problem. Archive brands like Undercover list era codes such as "06AW" and collection nicknames like "GURUGURU" in romaji on Japanese platforms, never translated. Translating them produces 404s. This required encoding explicit rules into the system prompt: Japanese brands become katakana, era codes stay in English, collection nicknames stay in romaji.

Yahoo Flea Market 404 diagnosis showing the five rules for Japanese search

The diagnosis a precise breakdown of why the Yahoo Flea Market URLs were returning 404s and what the correct query structure needed to look like.

Claude Code diff showing the six Japanese search rules being encoded into server.mjs

The fix encoded six explicit rules written into the system prompt, converting a fragile translation into a reliable one.

The Japanese platform problem

Archive brands like Undercover list era codes such as "06AW" and collection nicknames like "GURUGURU" in romaji on Japanese platforms, never translated. Translating them produces 404s. This required encoding explicit rules into the system prompt: Japanese brands become katakana, era codes stay in English, collection nicknames stay in romaji.

Before
paypayfleamarket.yahoo.co.jp/search?query=アンダーカバー+06AW+グルグル+コレクション+フライ+スパイダー+サイズ2
404 error
After
paypayfleamarket.yahoo.co.jp/search/アンダーカバー 06AW GURUGURU デニム
results found

The fix: brand in katakana, era code untouched, collection nickname in romaji, noise dropped. Four terms instead of eight.

Constraints and Tradeoffs

A large part of the project became designing around constraints rather than fighting them. Different platforms interpreted search syntax completely differently. Some responded well to broad natural language. Others required compressed keyword structures. Certain filters worked through URL parameters while others depended entirely on internal ranking systems.

There were features that sounded compelling but introduced too much fragility. Fully centralized listing ingestion, real-time inventory indexing, universal product normalization, and persistent cross-platform filtering each became increasingly expensive relative to the actual value they added. The more I iterated, the more I prioritized responsiveness, simplicity, and speed to useful results over technical ambition.

Private APIs blocked direct data access across most platforms entirely. UI scraping introduced a different kind of fragility. Listings structures changed without notice, anti-scraping protections evolved constantly, and any aggregation layer built on top would have been brittle by design. Those weren't just technical inconveniences. They were signals pointing toward a fundamentally different product.

I became less interested in building the most technically impressive system and more interested in building something people would genuinely enjoy using repeatedly.

Considered

Centralized listing ingestion, real-time inventory indexing, universal product normalization, persistent cross-platform filtering.

Chose instead

Deep-link routing to optimized searches. Lower infrastructure cost, faster response, and the marketplaces themselves handle the UX users already trust.

Testing session showing sizing filters not applying to URLs

A testing session that exposed a core constraint each platform encodes filters differently, requiring manual reverse-engineering of URL structures.

Expanding the Product Vision

Claude Code prompt showing the decision to evolve Archive Search into a broader platform

The moment Archive Search became Archive a deliberate decision to expand from a search tool into a platform for buying, selling, and understanding archive menswear.

One thing that surprised me was how often the best decisions came from recognizing gaps rather than adding features for the sake of it. The more I tested Archive personally, the more I realized search alone only served half the equation.

Buyers needed intelligent routing across platforms. But sellers had no systematic way to figure out what to charge. Buyers had no quick way to understand a brand's history or key pieces before searching. Archive had started as a search tool. Adding a pricing assistant and a deep dive panel made it something more complete, a resource for both sides of the resale market.

A recurring question shaped every decision: does this actually improve the experience, or does it just make the product feel more complicated? Not every capability deserves interface space. The ones that made it in earned their place.

Archive deep dive panel showing Guidi designer profile alongside search results

The deep dive panel a feature that emerged from recognizing a gap, not a roadmap. Search a designer, get their full archive profile alongside live results.

What I Learned

Archive changed how I think about products. I started the project thinking mostly about functionality and technical execution. I finished thinking much more about behavior, friction, and attention.

01
Scope is a product decision The move from aggregator to translation layer wasn't a technical compromise. It was a clearer understanding of what the product actually needed to do. Shipping the right thing matters more than shipping the most ambitious thing.
02
Simplicity is earned by removing things The best iterations came from pulling features out, not adding them. Every capability that didn't directly improve discovery made the product feel heavier without making it more useful.
03
The interesting opportunities live in the friction A lot of good product decisions come from noticing very small moments: repeated user effort, hesitation, broken momentum. The harder challenge is understanding where people lose energy interacting with a system.
04
Real constraints clarify product vision The most formative realization came from hitting actual walls. Private APIs blocked direct data access across most platforms entirely. UI scraping introduced fragility that would have made the product unreliable at its core. Those constraints weren't setbacks. They forced a clearer answer to the question of what Archive actually needed to be.

What's Next

Archive solves one side of the problem well. The natural extensions address the two biggest friction points that remain once you've found something you want to buy.

01
Legitimacy Authenticator A guided tool that helps buyers assess authenticity before committing to a purchase. The user would upload photos of a listing and describe the item — Archive would surface what to look for: known reproduction tells, stitching details, label variants by era, hardware specifics. The goal isn't to replace authentication services, but to reduce the number of purchases a buyer needs to run through them by filtering out obvious fakes earlier in the process. This is especially high-value in the Japanese market, where listing photos often omit the exact details that separate archive originals from replicas.
02
Fashion Identity Builder An onboarding flow for users who know they want to explore archive fashion but don't have a starting point yet. A short series of questions — about silhouette preferences, reference points, budget, and the kind of wardrobe they're building toward — would generate a curated set of designer and brand recommendations to investigate first. Rather than landing in front of a search bar with no vocabulary, users get a map: three to five designers with brief explanations of why they might resonate, and immediate search prompts to get started. It brings the guidance of a knowledgeable friend into the product for users who don't yet have one.