I tried it for my own products in October. The first attempts were bad. The later ones submitted 285 of 338 directories for one product and 690 across five campaigns. The model was the same both times. The difference was what I had written down for it.

Here are the five things.

1. What the directory is, before the page loads

An agent that has to discover each site from scratch wastes most of its run. So every directory gets a record. A trimmed one:

{
  "domain": "getmagictools.com",
  "submit_url": "https://getmagictools.com/submit",
  "login": "none for the free listing",
  "badge_required": false,
  "dofollow": "yes",
  "time_to_live": "reviewed within 30 days",
  "paid_tiers": "Pro, $9.90 once (skip)",
  "steps": ["Search the site for the product first...", "Fill in Tool Name and Tool URL", "Click Submit Tool"],
  "gotchas": ["No description field: the site writes the listing from your homepage."]
}

The fields that earn their place:

I collected 471 directories and checked each one by hand. 318 have a free listing. 36 are paid only, 16 were dead, 83 are flagged to skip.

2. Who it is when a site asks

Sign-up is the real obstacle, not the form. Across 1,304 recorded results, 848 went through Sign in with Google. Most of the rest wanted an email code.

So the agent works in a Chrome profile that's signed in to one Google account used only for launches. I sign in myself. From there it handles sign-ups, logins and one-time codes alone, and it never sees or types a password. It reads only the mail from the site it's working on.

3. One source of truth for the listing

Forms disagree about everything. One wants a one-line tagline, the next a full description. One wants two categories and five tags. One wants a 16:9 screenshot, another a 1400x950 preview.

The agent gets a single listing file with every length of every text, and a folder of images rendered up front in each size. It trims; it doesn't write new claims per site.

4. Permission to stop

This was the biggest fix. Without it, an agent loops on a form it can't finish or, worse, invents an answer.

"Needs a human" is a first-class result with a reason. In one 31-minute session on November 7, the agent worked 23 directories: 14 submitted, 1 already listed, 8 handed back.

The eight: two bot checks, two sign-ins where the open Gmail tab was the wrong account (my mistake), one listing that had become paid, one cookie banner it wouldn't accept on my behalf, and two forms asking for facts it didn't have, like the product's tech stack.

It also has hard limits. It never pays. It never posts votes, comments or reviews. If a site asks it to stop, it stops.

5. Memory outside the chat

Chat history is the wrong place to keep the state of 300 submissions. Each site gets a step log and a result file on disk. When an agent crashes or hits a quota, the next one reads the log and carries on, so nothing is submitted twice. At the end there's one report: every listing, its URL, its status, its follow-up date and any badge code.

You'll want that file. Directories write to you weeks later.

What it added up to

Three of the products were on new domains. Their Ahrefs Domain Rating went from 3 to 48, 2 to 36 and 0 to 33 between mid October and November 7. That's three products of my own, so it's an example, not a promise. I measured DR and nothing else.

The packaged version

I turned those five things into a product, the Launch Agent Kit: the database, the per-site steps, the listing template, the image pipeline and the tracker, as a folder your agent reads. It's mine, and it runs with Claude Code, Codex, Cursor, Antigravity, OpenCode, Copilot or Devin.

$29 once until December 1, then $99, with a DR 30 money-back guarantee for sites starting at DR 0 to 10.

swipetolaunch.com/kit

Or build your own from the list above. The order I'd do it in is 1, 4, 2, 5, 3.

A watermark tool that uploads your photos to a server asks photographers to hand over the very thing they're trying to protect. So we built ours to run entirely in the tab. You drop in up to 200 photos, set a mark, and get back one file or a zip. Nothing is sent anywhere.

The interesting part is that it isn't a separate project. The tool draws its watermarks with the same code our server uses for photos that are actually for sale.

One renderer, two rasterisers

sellphotos.online is a store for event photographers. When a photographer uploads a shoot, a processing container (Node 22 with sharp and libvips) draws a watermark over each preview that buyers browse. Those designs live in a folder of plain TypeScript, with no enums and imports written with .ts extensions. Node 22 strips the types at load time in the container, and Vite bundles the same files into the web app.

The core function returns an SVG string sized to one photo's frame:

renderWatermark(frame, designId, settings, logo) // → { svg, usedLogo }

On the server, librsvg rasterises that SVG and sharp composites it. In the browser, the SVG is loaded into an <img> and drawn onto a canvas over the photo. Same SVG, two rasterisers, so the SVG may only use features both draw the same way. We learned the rules by measuring:

• No textPath, textLength or text-transform. Letter-spaced text is anchored at its measured start, because browsers count trailing letter-spacing when centring and librsvg doesn't.
• Repeated text is <use> copies inside a rotated group, not a rotated <pattern>. At 2048 px the pattern took 1.8 s in the container and the group 0.3 s.
• No blur, shadow or morphology filters. They cost 6–10 s per photo on the server.
• Marks without a plate get a thin contrasting outline, so a white mark stays visible on a white sky.

Layout from the short edge

A batch mixes portraits, landscapes and squares, so a mark sized in pixels would look tiny on one photo and huge on the next. Every design sizes from the frame's short edge instead:

// workers/processor/container/wm/render.ts (simplified)
const base = Math.min(w, h);
export const margin = (c: Ctx, frac = 0.035) => Math.max(8, Math.round(c.base * frac));
export const sz = (c: Ctx, frac: number, min = 8) => Math.max(min, c.base * frac * c.k); // k = the user's size setting

Each photo in the batch gets its own SVG, rendered for its own width and height. A name in the corner sits the same distance in from the edge on a phone portrait as on a 3:2 landscape.

Branding marks, kept away from the store

The free tool has something the paid product deliberately doesn't: corner and edge marks. You pick a spot on a 3×3 grid (or every corner), a style (plain, badge, strip or a script signature), and whether a logo sits beside or above your text.

Those marks never reach a seller's previews. A corner mark is cropped off in seconds, so every design a seller can choose either crosses the middle of the photo or tiles the whole frame. The branding marks live in their own module, and the processor never sees them.

To keep the tool's preview and export code identical to the seller designs, a branding mark still travels as one number:

// workers/processor/container/wm/branding.ts (simplified)
// id = 1000 + style × 100 + layout × 10 + position
export function renderMark(frame, designId, settings, logo, opts = {}) {
  return isBrandingId(designId)
    ? renderBranding(frame, designId, settings, logo, opts)
    : renderWatermark(frame, designId, settings, logo, opts);
}

The font problem

An SVG loaded as an image is sandboxed. It can't fetch anything, including web fonts, so text silently falls back to a system font. The fix is to read which faces the SVG actually uses and inline those font files as data: URIs:

// apps/web/app/lib/tools/watermark-export.ts (simplified)
export function fontFacesIn(svg: string): FontFace[] {
  const seen = new Map<string, FontFace>();
  for (const m of svg.matchAll(/font-family="([^",]+)[^"]*" font-weight="(\d+)"( font-style="italic")?/g)) {
    const key = `${m[1]}/${m[2]}${m[3] ? "/italic" : ""}`;
    const file = FONT_FILES[key];
    if (file && !seen.has(key)) seen.set(key, { family: m[1], weight: Number(m[2]), style: m[3] ? "italic" : "normal", file });
  }
  return [...seen.values()];
}

Each woff2 is fetched once per page, base64-encoded, and cached in a Map of promises. A failed fetch is evicted so the next export retries it. The @font-face rules go into a <style> block inside the SVG, right after the opening tag. They're Latin subsets of the same font files the container has installed, so a mark looks the same in the tool as on a store's previews.

Export: one canvas at a time

// simplified
const source = await loadImage(photoObjectUrl);
const frame = outputFrame(source.naturalWidth, source.naturalHeight); // long edge ≤ 4,096 px
const { svg } = renderMark(frame, designId, settings, logo);
const overlay = await loadImage(URL.createObjectURL(new Blob([withStyle(svg, await embeddedFontCss(svg))], { type: "image/svg+xml" })));

const canvas = document.createElement("canvas");
canvas.width = frame.w;
canvas.height = frame.h;
const ctx = canvas.getContext("2d")!;
ctx.drawImage(source, 0, 0, frame.w, frame.h);
ctx.drawImage(overlay, 0, 0, frame.w, frame.h);
const blob = await toBlob(canvas, type, type === "image/jpeg" ? 0.92 : undefined);

The tool accepts JPEG, PNG and WebP up to 25 MB each. PNG stays PNG, because it may carry transparency, and everything else comes back as JPEG at quality 0.92. The long edge is capped at 4,096 px, plenty for the web and social media, and the original file on disk is never touched.

Photos are processed one after another, each on its own full-size canvas. So the 200-photo limit is about patience and zip size rather than memory. A cancel flag is checked between photos, and a cancelled batch saves nothing. When a photo is added, one object URL is created and reused by both the preview and the export, and a 320 px JPEG thumbnail is made for the list.

A zip writer in a few dozen lines

Browsers have no built-in zip writer, and the server's streaming one relies on node:zlib. JPEG and PNG files are already compressed, though, so a zip that only stores files loses almost nothing. That format is simple enough to write by hand: a CRC-32 per file, a local header before each file's bytes, a central directory and an end record.

// apps/web/app/lib/tools/client-zip.ts
export function crc32(data: Uint8Array, crc = 0): number {
  const t = (table ??= (() => {
    const t = new Uint32Array(256);
    for (let i = 0; i < 256; i++) {
      let c = i;
      for (let k = 0; k < 8; k++) c = c & 1 ? 0xedb88320 ^ (c >>> 1) : c >>> 1;
      t[i] = c >>> 0;
    }
    return t;
  })());
  let c = ~crc;
  for (let i = 0; i < data.length; i++) c = t[(c ^ data[i]!) & 0xff]! ^ (c >>> 8);
  return ~c >>> 0;
}

Names are written as UTF-8 (general-purpose flag 0x0800), and times as MS-DOS date/time. Files with the same name become a.jpg and a (2).jpg, compared case-insensitively. The detail that matters most for big batches is in zipBlobs. It reads each Blob once to compute its CRC, then puts the Blob itself into the output instead of a copy of its bytes. The whole batch stays in the browser's blob store, not in the page's JavaScript heap.

What "nothing uploads" buys you

• Trust you can check. Open the network tab while you export: there are no requests carrying your photos.
• No server cost per photo, so the tool can be free with no limits or sign-up.
• The trade-offs are honest ones. Output is capped at 4,096 px, and a big batch on an old phone takes a while. For photos you're about to post or send to a client, that's usually fine.

If you watermark photos you mean to sell, a corner mark won't stop anyone. That's why the paid side of sellphotos.online uses full-frame designs and only releases the clean original after the buyer has paid you. The watermark tool is free either way, with no account needed.

Every event on sellphotos.online gets a QR code. Photographers print it on posters, notice boards and table cards, or put it on the last slide at a prize-giving. Guests scan it in poor light, at an angle, through glare on a laminated sheet. We generate the codes ourselves with the small uqr encoder, then draw them with our own code. These are the decisions that came out of that.

Pick the error correction level per medium

QR codes carry Reed-Solomon error correction at four levels. Roughly, these are the share of codewords that can be recovered:

Higher levels need more modules for the same data, so at a fixed print size each module gets smaller. We use three levels, one for each place a code ends up:

• M for codes read off a screen. These are the UPI and Pix payment codes on a buyer's order page. A screen is flat, lit and clean.
• Q for printed event codes. Paper gets scuffed, laminate catches glare, and cheap printers blur edges.
• H when a logo sits in the middle, because the logo hides modules on purpose.

For scale: a 35-character event link such as https://sellphotos.online/e/AbC1234 comes out as version 3 (29×29 modules) at M, version 4 (33×33) at Q and version 5 (37×37) at H.

The logo hole

Plenty of generators paste a logo over the finished code and count on error correction to cope. We clear a square of modules first and draw the logo inside it, with a little padding, so no dark modules peek out around a transparent logo:

// apps/web/app/lib/qr.ts
export const LOGO_RATIO = 0.24;

export function logoHole(matrix: QrMatrix, ratio = LOGO_RATIO): QrHole {
  let size = Math.max(3, Math.round(matrix.size * ratio));
  if (size % 2 !== matrix.size % 2) size += 1; // same parity: exactly centred
  const x = (matrix.size - size) / 2;
  return { x, y: x, size };
}

The parity line is easy to miss. A QR code's side is always odd (21 + 4 × (version − 1)), so an even-sized hole can't sit exactly in the middle. (size − hole) / 2 would land on a half module. Bumping the hole to the same parity keeps it centred on whole modules.

The hole is 24% of the side. At version 5 with H, that's a 9×9 hole in a 37×37 code: 81 of 1,369 modules, about 6%. H can recover about 30%, so most of that margin is left for scuffs, glare and print blur. That's an approximation, since modules map onto codewords unevenly and codewords are interleaved across blocks. Even so, a hole of a few percent behind a ~30% budget leaves real slack.

Also check where the function patterns are. At version 5, the only alignment pattern sits near the bottom-right corner, well clear of a hole spanning modules 14 to 22. From version 7 up, alignment patterns appear in the centre as well, so a long URL with a logo would put one under the logo. Short links matter here.

Quiet zone, and a caption that stays out of it

The standard (ISO/IEC 18004) asks for four light modules on every side, and we keep all four. Photographers can add the event title as a caption. It goes in its own band below the quiet zone, so the zone stays clear. Long titles are cut at 40 characters, and the font size comes from a rough width estimate (a bold sans is about 0.58 em per glyph), so we never measure text.

One path string, three outputs

The Share dialog shows a live preview and offers an SVG download, PNGs and a printable table card. They all come from one function that turns the matrix into SVG path data, in module units:

// square style (simplified): each row's dark runs become one rectangle
for (let y = 0; y < size; y++) {
  let x = 0;
  while (x < size) {
    if (!data[y][x]) { x++; continue; }
    let end = x;
    while (end < size && data[y][end]) end++;
    parts.push(`M${x + margin} ${y + margin}h${end - x}v1h-${end - x}z`);
    x = end;
  }
}

Merging runs keeps the path short. The rounded style draws data modules as dots of radius 0.48, slightly under half a module so they stay distinct. It draws the finder patterns as nested rounded squares and fills them with evenodd, which punches out their holes.

That one string feeds three renderers:

• the React preview, as <path d={…}>
• the SVG download, where the path goes into a standalone document on a white background
• the PNG, drawn on a canvas with ctx.fill(new Path2D(d), "evenodd")

We never draw an SVG onto the canvas through an <img>. That keeps us clear of canvas tainting and of img-src rules for data: and blob: URLs, and because every output comes from the same geometry, they always match.

A few details on the PNG side:

• Whole pixels per module. modulePx = Math.floor(width / side), and the code is centred in what's left over. A fractional module size blurs the edges between modules.
• A size cap. The canvas stops at 4096 × 4096 pixels. The printable table card is A6 portrait at about 300 dpi (1240 × 1748 px).
• Fonts first. A canvas doesn't wait for web fonts, so we await document.fonts.load(...) before drawing the caption. Otherwise the first download comes out in a fallback font.
• The logo inside the SVG is embedded as a PNG data: URL, so the file stands alone when it goes to a print shop. It's re-encoded to PNG because design and print tools read PNG inside SVG, but not always WebP.

Colour

Photographers can pick a colour for the modules. We compute the WCAG contrast ratio against white and warn below 4.5. Our own note in the code puts the point where codes may stop scanning at about 3, so the warning fires with a margin to spare.

Keeping the encoder out of the client bundle

The encoder is small, but most visitors never need it, so we keep it out of the main bundle in two ways.

1. Lazy loading for sellers. The Share dialog loads its QR tab on demand, so uqr ships only in that chunk.
2. Server-only for buyers. The UPI payment code on a buyer's order page is built in the route's loader. React Router's client build drops loaders, and the QR module and uqr go with it. The browser receives a side length and a path string, and fills a Path2D:

// apps/web/app/routes/buyer/order.tsx (simplified)
// Loader only: used in a component, this would ship the encoder to every buyer.
function upiHandoff(p: UpiPayment) {
  const uri = upiUri(p);
  const matrix = encodeQr(uri, "M"); // read off a screen
  return { uri, qr: { side: matrix.size + QUIET_ZONE * 2, path: qrModulePath(matrix) } };
}

The comment is there for the next person to touch that file. One import from a component would quietly put the encoder back into every buyer's download.

What we'd check before trusting a design

None of this replaces printing the thing. Before calling a style or logo size done, we'd print it at the size people will actually use, scan it from across a room with an older phone, and try it under a ceiling light reflecting off laminate. The numbers above say how much damage a code should survive. Testing on paper shows whether it does.

The code above lives in a photo-selling app. Each event's QR code opens a gallery where guests find their photos with a selfie. If you're curious what's at the other end of the scan, there's a sample gallery.

Our sample gallery has 1,240 photos from a school spring festival. A parent opens it on their phone, takes one selfie, and sees "7 photos of you". Behind that one tap sits a pipeline that takes 100 MB originals from a photographer's browser, turns them into watermarked previews, and indexes faces, without the originals ever leaving storage.

sellphotos.online is a store for event photographers. They upload a shoot and share one link or QR code. Guests find their photos with a selfie and pay the photographer directly. This post covers the plumbing. Three constraints shaped all of it:

1. The originals are the product. Buyers pay for them. A leaked original is a lost sale.
2. Guests won't install an app. They're at a gate or in a WhatsApp group, opening a link on whatever phone they have.
3. Photographers upload thousands of files at once, in whatever their camera or phone writes, including iPhone HEIC.

The app is React Router (framework mode, SSR) on Cloudflare Workers, with D1, R2, Queues and a Cloudflare Container for image work.

The whole pipeline

photographer's browser
  │  presigned PUT (≤ 20 MiB) or multipart (10 MiB parts)
  ▼
R2 originals ──(object-create notification)──▶ Queue ──▶ processor Worker
                                                              │ streams the original in
                                                              ▼
                                               Container: Node 22 + sharp/libvips
                                               (no internet, no credentials)
                                                              │ meta + watermarked WebP + smaller sizes
                                                              ▼
                                processor Worker: writes previews to R2, status = ready in D1
                                                              │
                                                              ▼
                                face indexing: the gateway fetches the WATERMARKED preview

guest's phone ─▶ gallery of previews ─▶ selfie ─▶ matches ─▶ pays the photographer ─▶ approved ─▶ original

1. Uploads go straight from the browser to R2

The Worker never proxies photo bytes on the way in. The browser asks for upload slots, up to 50 files per call. The app checks the plan's quota, inserts rows with status uploading, and returns presigned URLs: one PUT for files up to 20 MiB, or a multipart upload with one presigned part per 10 MiB above that. The URLs live for an hour and can be re-minted while the photo is still uploading.

Two details matter more than they look.

The client never picks the object key. Keys are {storeId}/{photoId}.{ext}, the extension comes from the MIME type, and the store and photo IDs are signed into the URL as object metadata. The original filename lives only in the database, after normalisation: bidi controls are stripped, so a U+202E can't fake an extension.

Duplicates are caught twice. Before uploading, the browser asks which files the event already has. It matches on name, size and lastModified first, then MD5-hashes only the size matches, so re-dropping a folder doesn't re-upload it. Those browser hashes are hints, though. The processor computes the MD5 of the original and has the final say.

2. R2 tells a queue, and a backup message covers lost events

An object-create notification on the originals bucket puts a message on a Queue. Before doing anything, the processor checks three things: the key is canonical, it matches the row's original_key, and its prefix is the row's store.

Event notifications can go missing, so there's a second path. When the browser calls /uploads/complete, the app enqueues a render message delayed by 15 minutes, which only acts on a photo still stuck in processing. An hourly reconciler picks up anything both of them miss.

3. A container that can't call anyone

The processor Worker streams the original into a Cloudflare Container running Node 22 with sharp and libvips. The container decodes and auto-orients the photo, then draws one of 27 watermark designs. It sends back a multipart response with three parts: JSON metadata (MD5, dimensions, capture time, dominant colour), a 2048 px WebP preview, and smaller sizes.

The container runs with enableInternet = false and holds no credentials. The Worker does every R2 and D1 write itself.

The reason is HEIC. sharp's prebuilt libvips can't decode HEVC, so HEIC files go through libheif's heif-convert to a lossless PNG first. libheif and libde265 are C/C++ parsers of untrusted input, with a steady stream of memory-safety CVEs. We pin libheif to an upstream release and build only the HEVC decoder. Its default security limits stay on, sharp's 300 MP pixel limit is checked against the header before decoding, and it runs via execFile with fixed arguments.

All of that helps, but the real defence is the box. Suppose someone got code execution inside the decoder. They could reach the one image they were handed and nothing else: no bucket, no other store's photos, no network.

HEIC had other surprises:

• Gain maps. iOS 18 HEICs carry an ISO 21496-1 gain map, roughly 40% of the photos in a recent iPhone library. The older libheif in Debian bookworm refused every one of them. The preview now uses the SDR base image.
• Orientation, once. libheif applies irot/imir, and iPhones also write EXIF Orientation, so that path must not auto-orient a second time.
• Colour. iPhones embed a Display P3 profile. Some Android phones signal P3 only through an nclx box, so we insert the P3 profile before converting to sRGB.
• Bursts and edited stacks have several top-level images. We keep the primary one.

Watermark or nothing

This rule has the most code behind it. No code path copies original bytes into the previews bucket. The container rasterises the overlay as its own RGBA layer, then counts its visible pixels:

// workers/processor/container/watermark.js (simplified)
const MIN_COVERAGE = 0.0005; // 0.05% of the frame
let visible = 0;
for (let i = 3; i < data.length; i += 4) if (data[i] >= 8) visible++;
if (visible < width * height * MIN_COVERAGE) {
  throw new WatermarkError(`design ${designId} produced an empty overlay`, "watermark_empty");
}

A bad SVG, a logo that won't decode or an empty overlay each returns a permanent 422, and the Worker only writes previews from a 200.

Smaller sizes are drawn, not downscaled

Phones load images from 320 to 1536 px wide. Downscaling the 2048 px preview was the obvious move, but fine watermark patterns average away when you shrink them. We measured the share of pixels the mark visibly changes, per mille, over six real photos:

So the container draws the watermark again at 1536, 1024, 640, 480 and 320 px. It costs CPU: when we added the four smaller sizes, a render of about a second on an M3 got roughly 0.4 s slower. In exchange, a 320 px thumbnail is as hard to reuse as the full preview.

Each photo is also rendered exactly once. Changing your watermark later only affects new uploads, so a store with 50,000 photos doesn't re-decode 50,000 originals over a logo tweak.

4. Retries that don't lie

Queues deliver at least once, and the container can be busy, restarting or gone. Each failure gets its own lane:

Back-pressure shouldn't eat a photo's retry budget. Queues has no retry that doesn't count, so "busy" and "unreachable" become fresh messages that carry their own counters in the body.

D1 has no transactions you can hold open and no row locks, so correctness comes from guarded statements. The final write looks like this:

-- simplified
UPDATE photos
SET status = 'ready', preview_key = ?, md5 = ?, width = ?, height = ?
WHERE id = ? AND deleted_at IS NULL AND original_key = ?
  AND NOT (status = 'ready' AND preview_key IS NOT NULL);

The first render to commit wins. If zero rows change, either the photo was deleted mid-flight or a duplicate delivery got there first, and the preview we just wrote gets cleaned up. The duplicate check works the same way: one atomic batch() sets the MD5, soft-deletes newer copies in the same event (never one that has sold), and queues their R2 deletes.

Capacity is matched end to end. Ten container instances run two images each, so 20 at once, and the consumer runs max_concurrency 4 × max_batch_size 5, also 20.

5. Face indexing sees only what the public sees

Faces are indexed by SightRadar, our face-recognition service, with one collection per event. We don't send it files. It fetches each photo's watermarked preview from the public image route at ?w=2048, and that route has no code path to the originals bucket.

Indexing is batched, up to 1,000 photos at a time, and arranged so a crash can neither lose a batch nor pay for it twice:

1. In one D1 batch, write an intent row and mark the photos sent. The idempotency key is a hash of the sorted photo IDs and their attempt counts.
2. Submit the batch under that key.
3. If the Worker dies between steps 1 and 2, the next run re-submits the intent under the same key. The gateway replays a key it has already seen without charging again.
4. Poll the batch with backoff for about an hour. When configured, a signed webhook (HMAC-SHA256 over timestamp and body, ±300 s) settles results sooner.

6. The guest side: a link, a camera, no app

The guest scans a QR code on a poster and lands in a gallery of previews. "Find my photos" opens a short notice first, covering what a face template is, that it's used for this event only, and how long it's kept. The camera opens only after "Agree and take a selfie".

The camera is plain getUserMedia. It opens front-facing, mirrored in the preview, though the image that's sent isn't mirrored. "Find someone else" opens the rear camera, for a parent photographing their child. The phone checks the selfie before anything is uploaded. A photo under 160 px on its short side, one that's too dark (95th-percentile luma under 50), or one with two faces of similar size (where the browser has FaceDetector) is refused locally, without using up a search.

On the server, the selfie image is never stored. It becomes a face template, and the search result is cached for 24 hours for the browser that made it. Photographers can turn on "Live camera only", so nobody can search with someone else's photo from their camera roll. They can also delete an event's face data entirely.

Then the guest buys single photos, "all my photos" or the whole event. They pay the photographer directly, by UPI, PayPal, bank transfer or whatever the photographer accepts, and upload a screenshot. Once the photographer approves, /dl checks the buyer's entitlement and streams the original from R2 with Cache-Control: private, no-store.

What we'd tell someone building this

• Put the parser of untrusted files in a box with no network. Then keep patching it anyway.
• On D1, write every multi-step change as one batch() guarded by WHERE clauses. "First commit wins, then clean up" is simpler than locks you don't have.
• Give back-pressure its own retry counter. Otherwise one busy hour fails good photos.
• Measure what the user actually sees. We almost shipped thumbnails whose watermark had mostly vanished.
• Send the face service the same image the public sees. Then "what if it leaks?" has a boring answer.

What's next: AVIF came in at about half the bytes of WebP at 1024 px, but it encodes about twice as slowly and needs a Vary: Accept that our cache keys don't have, so it's parked for now.

If you want to see the guest side without uploading anything, there's a sample gallery with a simulated selfie search. Questions about any of the pieces above are welcome in the comments.