This post is still being written — please check back later. Posted: May 2026.
Bountylist started as a marketplace for small bounties aimed at serial hackers — post a problem, set a reward, let developers compete to solve it. It has since grown into spread.xyz, a generalized marketplace where the same homepage feed shows roles, résumés, and small jobs side by side.
The interface decision
The site is a deliberate Craigslist clone. Black text on a white page, 13px Helvetica, purple links, dotted section underlines, no rounded corners, no cards, no hero. The whole homepage is three columns of directory entries arranged taxonomically: community, blog, events on the left; for-sale, services, research in the middle; jobs, résumés, receipts, discussion forums on the right. Each column item is a plain text link.
This was the early product decision, and it's load-bearing. A marketplace with three users feels like a ghost town if it shapes itself like Stripe or Lever, because the chrome implies a scale the data doesn't have. A directory page shaped like Craigslist reads as populated even when most of the rows are static taxonomy — the eye can't immediately tell which links go to live listings and which go to static category pages. The site feels useful before it is useful. The cost of this choice is that the interface looks like 1998 to people who weren't raised on it; the benefit is that it onboards bounty posters and recruiters without any explanation of what the product is.
The /jobs view
Jobs and bounties share one listing format: a date, a one-line title, a price, and an open/closed state. Prices range from $50 for a Spotify email scrape to $10k for an eval leaderboard to $$$ for "build AGI." The interface refuses to distinguish between serious requests and joke requests, because the people who post on a Craigslist-shaped board enjoy that ambiguity. Real listings get answered; joke listings turn into recruiting copy.
Single-blind contact
The interesting machinery is the messaging layer. When you reply to a listing the system mints a tagged forwarding address — apply+<listingId>@spread.xyz — and routes mail through it. Both sides write back without ever seeing the other's real address.
The Cloudflare Worker email handler accepts inbound mail at that tagged address, looks up the listing's Durable Object, and fans the message out to whichever real address is on the other side of the thread. Single-blind is preserved end-to-end: neither party sees the other's real email until both opt in. The aliasing also means recruiters can keep applicants warm without leaking either side's address into a CRM.
How state lives on both sides
The same conversation has to look right in Gmail and in /inbox, and replies typed in either surface have to land in the same thread. That works because every thread is one Durable Object, with a small SQLite schema inside it: a message table (one row per send/receive — direction, from, to, subject, body, the Cloudflare message id, the In-Reply-To header, a timestamp) and a meta table that pins the real poster email, the real recruiter email, and the canonical subject. The DO is named by the thread id (in v1 that's just the listing id, so each listing has at most one open conversation).
When the recruiter hits Send the first time, the worker creates the ThreadDO, persists the outbound row, then sends from apply+<listingId>@spread.xyz with the poster's real address as the recipient — so the poster's Gmail thread is anchored to the proxy address forever. When mail comes back in, Cloudflare Email Routing delivers it to the worker; the worker parses the apply+<id>@ tag, opens the DO by name, appends an inbound row, and sends the canonical-subject copy out to whichever real address is not the sender. The In-Reply-To and cf_message_id are stored so threading stays intact across both surfaces.
The /inbox view is just the DO's own log. Because the only authenticated viewer is one of the two participants, the worker is the only place that ever knows both real addresses — they live in the meta table and never leave it. The other side's emails always show the proxy address as the From, and any reply they type lands on the worker first.