Meebit NFT marketplace

Context and commercial aim

MeebMarket is a third-party marketplace aggregator for the Meebits collection. The goal was not to clone the official brand site, but to build a focused trading and discovery surface around a complete 20,000 item catalogue, with the product experience hosted on Cloudflare from the edge API down to the data stores and media path.

The business value is in joining the pieces that are usually scattered across generic marketplace pages, token tools, wallet modals, and social links. A visitor can browse the collection, filter by traits, inspect a specific Meebit, compare listings, buy through NFTX, swap one Meebit for another, watch for listing changes, and share a token page that renders cleanly in search and social contexts.

That makes the project a useful Simple Things case study because it combines product design, Cloudflare architecture, Web3 transaction design, SEO, analytics, operational runbooks, and the unglamorous reliability work that makes the whole thing usable after launch.

Product surface

The catalogue is the centre of the experience: all 20,000 Meebits are queryable through a D1-backed API, with filters for type, trait combinations, rarity ordering, price ordering, ownership views, trait landing pages, and detail pages for each token. The browsing model was designed to make a dense collection feel approachable without flattening away the technical data collectors care about.

The buy flow and swap flow are intentionally product-shaped wrappers around more complex onchain actions. A buy quote prepares a single transaction that routes ETH into the required vault action; a swap quote supports Meebit-for-Meebit movement with the required approval step and transaction state surfaced in the UI. The implementation keeps the language user-facing while still preserving the operational detail needed for debugging.

Engagement loops were added around the marketplace rather than bolted on later. The live activity feed gives the site a sense of market movement, watchlist alerts let users opt into listing and price-drop signals, and analytics events give a way to measure views, wallet connection, quote attempts, transaction signing, transaction success, and browsing paths.

Architecture

The app uses a Cloudflare Worker as the main entry point. Hono handles API routes, canonical redirects, health checks, image and OG routes, SEO surfaces, and the fallback to the Vite-built React app. The Worker runs before static assets, so the same deployment can serve API behaviour, server-side metadata, and client application routes from one Cloudflare application boundary.

D1 stores the durable product model: Meebit records, traits, listing snapshots, watchlist subscriptions, alert state, skin-tone fields, report records, and fee-related audit structure. KV handles hot cache values such as NFTX pricing and summary data. R2 and Cloudflare Images support the media path. A Durable Object acts as the activity hub, holding a recent event buffer and streaming updates to browsers.

The scheduled indexer refreshes marketplace data on a five-minute cadence. It pulls OpenSea listing data, collapses multiple orders down to the cheapest active order per token, fetches NFTX vault holdings and current buy price, writes the resulting listing cache, updates the KV floor-price cache, and then triggers watchlist alerts. Importantly, one source failing does not stop the other source from updating.

Iteration history

Iteration 1 - Capture the live baseline. The starting point was already beyond scaffold: a live Cloudflare-hosted marketplace with catalogue browsing, indexer, wallet flows, activity feed, email alerts, dynamic OG, Cloudflare Images support, skin-tone tooling, Turnstile, and analytics. The first documentation pass rewrote the README to reflect the actual production state rather than an early prototype description.

Iteration 2 - Make operations reproducible. The deployment model was made explicit through wrangler.jsonc, D1 migrations, package scripts, a one-shot provisioner, seed tooling, and local development commands. This matters because Cloudflare-native projects can otherwise become dashboard knowledge. Here the Worker, assets, database, cache, bucket, images binding, Durable Object, cron trigger, migrations, and secrets model are all represented in code or runbooks.

Iteration 3 - Remove type and correctness friction. Several small fixes were deliberately handled before deeper feature work: a robots.txt newline issue, dead SwapModal branch checks, HTMLRewriter handler return types, the caches.default TypeScript gap caused by DOM typings, unused Worker values, and a deploy script that now runs tsc --noEmit before building and deploying. None of these are headline features, but together they reduce the chance of a fragile production release.

Iteration 4 - Make token pages indexable. The original per-token route had rich client UI but thin server-rendered output. The SEO iteration used HTMLRewriter to inject page-specific metadata, JSON-LD, and crawlable HTML into the app shell for /meebit/:id. Crawlers now see headings, token context, item images, trait links, prev and next links, and a gallery route without needing to execute the React app.

Iteration 5 - Add honest structured data. Search Console guidance drove a second SEO pass: token pages now combine Product and VisualArtwork JSON-LD, attach an Offer when an exact listing exists, and use a limited-availability floor-price fallback when there is not a direct listing but NFTX provides an indicative acquisition route. The important detail is honesty: the schema distinguishes an exact token listing from a collection-level vault path.

Iteration 6 - Improve internal discovery. The Meebit detail page gained prev/next navigation and a similar-by-trait row. The similar endpoint chooses representative rare matching tokens per shared trait and avoids duplicate picks. This is useful for users, but also strengthens the internal link graph around the catalogue in a way that is measurable through analytics events.

Iteration 7 - Move media work off the hot path. The image migration was driven by a real Worker constraint: large upstream renders and OG generation can trip CPU limits on cold social card renders. The fix moved images toward R2 and Cloudflare Images variants, with resumable bulk upload scripts, named variants for thumbnails/detail/OG, R2-backed OG fetches, cache versioning, and fallback paths for safe rollback.

Iteration 8 - Add trust, alerts, and moderation loops. Watchlist alerts use double opt-in email verification, one-click unsubscribe, and indexer-driven diffs for new listings, sales, and price drops. Skin-tone tooling samples image regions, stores raw values, supports palette snapping, records confirmation state, and accepts Turnstile-gated community reports. This is a good example of product polish becoming operational data design.

Public-safe boundaries

The public case study should show the architecture, product decisions, and iteration path, but not publish account identifiers, secret values, admin credentials, exact webhook verification mechanics, provider keys, internal account settings, or private operational routes. The current copy intentionally talks at capability level where more detail would create unnecessary attack surface.

Likewise, the transaction work should be described in terms of user journey and route shape rather than exposing any private signing material or privileged operations. Contract addresses and public protocols are not secret, but the stronger portfolio story is the system design: a Cloudflare-native marketplace that combines catalogue data, onchain execution, media delivery, SEO, analytics, and operations into one maintained product.

What this demonstrates

MeebMarket shows Simple Things operating across product and infrastructure at the same time. It is not just a frontend skin over existing marketplaces, and it is not just backend plumbing. It is a complete specialist product surface with crawlable pages, real-time updates, wallet actions, generated imagery, alerting, deployment discipline, and enough instrumentation to keep improving it after release.

Deployment model

Deployment is intentionally Cloudflare-native. There are no repository-level GitHub Actions in the current repo; the release path is the local or CI-friendly command path of tsc --noEmit, vite build, and wrangler deploy. That keeps the deploy small, direct, and aligned with the platform that actually runs the application.

The Worker is configured to run before static assets and then fall back to the SPA shell. That allows the same Cloudflare deployment to own JSON API routes, canonical redirects, robots and sitemap responses, OG images, HTMLRewriter metadata injection, and React application delivery without a separate Node server.

D1 migrations own the product schema, while the provisioner script creates or wires the core Cloudflare resources for a fresh environment. Bulk data and media jobs are handled through explicit scripts: seed fetch/apply for the 20,000-token catalogue, Cloudflare Images upload for renders, and skin-tone extraction for collection-specific browsing metadata.

The public case study should describe this as a low-ops deployment model: Workers, assets, D1, KV, R2, Images, Durable Objects, cron, Wrangler, migrations, observability, and runbooks. It should not publish database IDs, namespace IDs, account hashes unless deliberately public, secret names beyond generic categories, admin secrets, or provider tokens.