I wanted a draw where:

1. nobody needs an account, not even the organizer;
2. everyone joins from one link with just a name;
3. couples (or a manager and their reports) can be kept apart;
4. the organizer's screen never shows who has whom.

Here's how the Next.js (App Router) + Prisma/Postgres app behind it works, including the trade-offs I'm not claiming to have solved.

1. Three kinds of links, three kinds of power

There are no users and no sessions. Access comes entirely from which URL you hold:

The IDs come from nanoid's customAlphabet, using alphabets without look-alike characters:

// Public join slug: short, URL-safe
export const makeSlug = customAlphabet("23456789abcdefghjkmnpqrstuvwxyz", 10);

// Long secret tokens (organizer / reveal)
export const makeSecret = customAlphabet(
  "23456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghjkmnpqrstuvwxyz", 24);

That's 24 characters from a 55-symbol alphabet, about 138 bits, so the tokens can't be guessed. The slug is only about 49 bits. That's fine, because all a slug lets you do is join.

The "organizer can't peek" property comes from what each page queries and renders:

• The manage page loads participants and exclusions but only passes { id, name } to the client. Once the draw has run, the page just says assignments live on each person's private link.
• The reveal page looks up a participant by revealToken, checks that the token belongs to that slug, and only then loads the one person in givesToId.
• The private pages set robots: { index: false } and referrer: "no-referrer", so the tokens don't leak through search results or the Referer header when someone clicks a wishlist link.
• When you join, your reveal token is saved in localStorage for that slug. The public join page can then show a "See who I'm buying for" button on that device without the token ever appearing in the group chat.

The honest caveat: the server does store givesToId, because it has to show you your match. So this is "the organizer can't see it", not "nobody can". The operator, which is me, could query the database. A stronger design would encrypt each assignment so only the matching reveal token can decrypt it. That's on the list; I'd rather say what isn't done than oversell it. The other trade-off is losing your link. The organizer can't look up your match, because that's the point. They can only start a fresh draw.

2. Exclusions: a derangement with constraints

A Secret Santa assignment is a permutation with no fixed points (nobody draws themselves), which is a derangement. Exclusions add more forbidden edges. I store them as directed pairs (fromId must not give to toId), so a couple is simply two rules, and "A can't draw her boss, but the boss can draw A" can also be expressed.

The algorithm is deliberately simple:

// forbidden: Map<giverId, Set<receiverId>>, always containing self
for (const id of participantIds) {
  const blocked = forbidden.get(id)!;
  if (participantIds.every((other) => blocked.has(other))) {
    throw new Error("Could not find a valid draw with the current exclusions...");
  }
}

for (let attempt = 0; attempt < maxAttempts /* 800 */; attempt++) {
  const receivers = shuffle([...participantIds]); // Fisher–Yates
  const mapping = new Map<string, string>();
  let ok = true;
  for (let i = 0; i < participantIds.length; i++) {
    if (forbidden.get(participantIds[i])?.has(receivers[i])) { ok = false; break; }
    mapping.set(participantIds[i], receivers[i]);
  }
  if (ok) return mapping;
}
throw new Error("Could not find a valid draw with the current exclusions...");

Why rejection sampling instead of a clever constructive algorithm?

• It's uniform. Each shuffle is a uniformly random permutation, and we keep the first one that passes. So every valid assignment is equally likely. The common "everyone in one big circle" approach can't produce assignments made of several smaller loops. Naive greedy backtracking that takes the first receiver that works is also biased.
• It's fast where it matters. With no exclusions, about 1/e ≈ 37% of random permutations are derangements, so 800 attempts basically never fail. Typical family or office exclusions (a few couples in a group of 8–30) barely change that.
• It fails loudly. The pre-check catches the obvious impossible case (someone has excluded everyone). If 800 shuffles all fail, the API returns a readable error ("loosen exclusions or add participants") before anything is written.

That pre-check is necessary but not sufficient. Three people who can each only give to the same one person pass it, and still have no solution (in matching terms, Hall's condition fails). For dense constraint sets, the right upgrade is backtracking: shuffle the candidates, assign givers with the fewest options first, and undo when you hit a dead end. Or check feasibility with a bipartite matching first, and only sample once you know a solution exists. Small groups haven't needed that yet, so I haven't shipped it.

Running the draw is one Prisma $transaction: every givesToId update plus status: "DRAWN". Either the whole draw is saved or none of it is. Once a draw is DRAWN, both the run endpoint and the exclusions endpoint return 409.

3. A unique OG image for every draw

Most people meet DrawSage as a link pasted into WhatsApp or iMessage, so the preview card does most of the selling. Next's file convention makes a preview for each draw almost free: put an opengraph-image.tsx next to app/draw/[slug]/page.tsx.

export const size = { width: 1200, height: 630 };
export default async function Image({ params }) {
  const { slug } = await params;
  const draw = await prisma.draw.findUnique({
    where: { slug },
    select: { title: true, budgetMaxCents: true, _count: { select: { participants: true } } },
  });
  // title (truncated to 70 chars, font size stepped by length),
  // "Budget up to $X", "N people already in", and a "Tap to add your name →" pill
  return new ImageResponse(/* JSX */, size);
}

Two details matter here. First, the card shows counts, never names. Second, join pages are noindex but not blocked in robots.txt, so link-preview crawlers can still fetch them while search engines leave them out.

4. AI gift ideas with a deliberately boring fallback

After the draw, your reveal page shows gift ideas for your recipient, based on their wishlist and the group's budget. The implementation is:

• One call to an OpenAI-compatible /chat/completions endpoint. The base URL and model come from env vars; I point it at DeepSeek. The call uses response_format: json_object, a 12-second AbortSignal.timeout, and a prompt that says to stay at or under the budget maximum.
• Caching: the cache key is a SHA-256 of the input JSON plus the model name. Results go in a GiftSuggestionCache table for 7 days. Identical requests, like the same budget and the same empty wishlist, are common in December, so the cache saves real money.
• Fallback: if there's no key, the request times out, the JSON doesn't parse, or the list comes back empty, a hand-curated catalog of about 35 items takes over. Items are scored by interest tags and wishlist words, and anything over 115% of the budget is dropped. The user always gets 8 ideas and never sees an error.
• Rate limiting: 30 requests a minute per IP, kept in memory. That's crude, but enough for an MVP.

Gift links are Amazon search links. When an Associates tag is configured, they're affiliate links, and the UI says so next to the ideas.

What I'd do differently or next

• Encrypt each assignment under the matching reveal token, so the database alone can't reveal the pairings.
• A feasibility check (bipartite matching) when exclusions are added, rather than only at draw time.
• Use crypto.getRandomValues for the shuffle instead of Math.random. For a gift exchange this is more about appearances than real security, but it's cheap.

If you've built something similar, or know a neat sampling method for heavily constrained derangements, I'd love to hear about it in the comments.

Disclosure: I built DrawSage, the free, no-signup Secret Santa tool this post describes. You can try it at drawsage.com.