Field Notes: Building a Web3 Marketplace

What "Marketplace" Actually Means

A marketplace is the most deceptively complicated thing you can build. The pitch is "users post listings, other users buy them." The reality is inventory, search, messaging, payments, identity, moderation, disputes, and the small army of admin tools that keep the whole thing from collapsing.

CryptoRabbit is a marketplace for digital assets, with mobile and web clients. This is a tour of the parts that turned out to matter.

One Backend, Two Clients

The product is a Next.js web portal and a React Native app. They share a serverless backend on AWS Lambda — one set of endpoints, one set of business rules, two presentation layers.

The thing that pays for itself with this structure is consistency. Listing rules, fee math, transaction flow — all of it lives in Lambda. The clients render. When the rules change, you change them in one place and both clients see it on the next deploy.

The thing it costs you is platform-specific UX. Sometimes the right mobile pattern is genuinely different from the right web pattern. Sharing a backend does not let you share a screen, and pretending otherwise produces interfaces that look halfway native everywhere and properly native nowhere.

Payments Without the Usual Pain

Crypto-adjacent payments come with their own etiquette. QR codes turned out to be the right primitive — a buyer scans, a seller approves, the transaction settles, both clients update. It is a smaller surface than a full hosted-checkout flow, and it fits the way users actually transact.

The lesson, which is not really a crypto lesson: pick the smallest payment primitive that fits the transaction shape, and resist the urge to recreate Stripe's hosted page in your own UI. Less code, fewer moving parts, fewer edge cases that break at the worst time.

Where AI Earns Its Keep

The most interesting AI work in this product is not user-facing. It runs on the listing pipeline.

When a seller posts a new item, an AI step runs against the listing before it goes live. It checks the title against the description, the description against the images, the images against each other. It catches the two failure modes that destroy marketplace trust: low-quality listings and outright scams.

A few things make this work:

• It runs on submit, not on display. Bad listings never make it to the index. The trust signal compounds because users never see them in the first place.
• It augments, not replaces, human moderation. The model flags; a human approves the flag. The model is the filter, not the verdict.
• It is cheap per listing. A few cents of inference saves hours of moderation, which is the only reason it pencils out.

This is the kind of AI feature that does not show up in a marketing page but is the reason the marketplace works at all.

Search Is the Whole Experience

In a marketplace, search is the product. People do not browse — they look for the thing they came for. We invested heavily in making search feel responsive and accurate, with structured filters layered on top of a relevance ranker.

The pattern that worked: lean on database indexes for the structured filters, and only fall back to fuzzier matching when the structured query returns too little. The hybrid keeps the fast path fast and reserves the expensive path for the cases that need it.

Admin Tools Are Half the Product

The dashboard does not appear in any user-facing release notes, but it is where the marketplace actually lives. Approvals, refunds, suspensions, listing corrections, transaction lookups — all of it goes through tools we built for ourselves.

The mistake to avoid: treating admin tooling as a follow-up project. Marketplaces start failing the day a transaction goes wrong and the operator cannot fix it. Build the admin tools alongside the user tools, not after.

Takeaways

• Share the backend across web and mobile. Keep room for platform-specific UI.
• Pick the smallest payment primitive that fits the transaction shape.
• Use AI on the submission path, not just the consumption path.
• Treat search as the product, not a feature.
• Build admin tools at the same time as user tools.