Forem: Jean Michael Mayer

Show Dev: I Built an AI Gift Whisperer in a Weekend

Jean Michael Mayer — Fri, 24 Apr 2026 17:09:10 +0000

The problem nobody wants to admit

Gift-giving is a search problem with terrible inputs. You know your sister is 34, into pottery, allergic to cilantro (somehow relevant), and hates anything monogrammed. What you don't know is what to buy her that won't end up in a drawer.

Existing "gift finder" sites are SEO farms with affiliate links and a quiz that asks if the recipient is "fun" or "practical." Cool, thanks.

So I built The Gift Whisperer. You describe someone you love in plain English, and it returns 12 real gift ideas, an illustrated card, and a message that actually sounds like you wrote it (but better).

Why it's a separate service

I run a few small apps under one umbrella. My first instinct was to bolt this onto the monolith as another route. I didn't.

The Gift Whisperer does three things that the rest of my stack doesn't:

Long-running LLM calls (sometimes 15–30 seconds for the full payload)
Image generation that spikes memory
Bursty traffic around holidays

Sharing a process with my normal CRUD apps means one slow gift request blocks everything else. So it lives in its own Railway service with its own scaling rules and its own crash blast radius. If it dies on Mother's Day, the rest of my stuff keeps humming.

Isolation is underrated. Microservices are overrated. The truth is boring: put the weird workload in its own box.

The prompt is the product

The actual interesting engineering here isn't the framework choice (Next.js, shocker). It's the prompt pipeline.

A single "give me 12 gifts" prompt produces garbage — either generic Amazon bestseller slop or bizarre hallucinations ("a handcrafted ferret hammock"). So I split it into stages:

Extract traits from the free-text description into a structured profile
Generate candidates across price tiers and categories in parallel
Re-rank and dedupe against the original description
Generate the card + message using the refined profile, not the raw input

Stage 2 looks roughly like this:

const tiers = ['under_25', 'under_75', 'splurge'];

const candidates = await Promise.all(
  tiers.map((tier) =>
    openai.chat.completions.create({
      model: 'gpt-4o-mini',
      response_format: { type: 'json_object' },
      messages: [
        { role: 'system', content: GIFT_SYSTEM_PROMPT },
        { role: 'user', content: JSON.stringify({ profile, tier, count: 4 }) }
      ]
    })
  )
);

const ideas = candidates.flatMap((c) => JSON.parse(c.choices[0].message.content).gifts);

Parallelizing per-tier cut total latency roughly in half and — more importantly — forces variety. A single call to "give me 12 ideas across budgets" consistently clusters around the middle tier. Splitting the constraint into separate calls fixes that without any clever reranking.

The illustrated card was the hard part

LLMs are great at text. Image models are great at images. Getting them to agree on what the gift actually looks like is the hard part.

I pass the top-ranked gift idea plus a stripped-down style prompt to the image model. No recipient details, no names, no "make it feel warm and personal" — image models interpret that as cursed stock photography. Constraints beat vibes.

Why "a message that slaps" matters

The gift ideas are table stakes. The note is the moat. I spent more time tuning the message prompt than anything else, because a good gift with a generic card is still forgettable. The message prompt explicitly avoids words like journey, cherish, and blessed. You're welcome.

Try it

Got someone hard to shop for? Go describe them:

👉 gift-whisperer.edgecasefactory.com

Free to try. Takes about 30 seconds. Bring receipts if it nails it — I want to know what worked and what didn't.

Show Dev: An Idle Tycoon Game Where You Can't Click

Jean Michael Mayer — Thu, 23 Apr 2026 23:52:01 +0000

The dumbest game I've ever shipped

I made a tycoon game where clicking does nothing. There are no upgrade buttons, no prestige loops, no "slap the cookie" dopamine. You open the tab, and numbers go up. That's it. That's the game.

It's called The Lazy Tycoon, and it's the purest expression of the idle genre: the player has been removed entirely.

This started as a bit. I was complaining that "idle" games aren't really idle — they demand more clicks per minute than most action games. So I built the logical endpoint: a game that plays itself while you watch.

Why remove the player?

Every idle game I've played eventually turns into spreadsheet homework. You sit there tapping a prestige button every 47 minutes because the meta demands it. The "idle" part is a lie told by the onboarding tutorial.

By removing input entirely, a few interesting things happen:

The game has to be legible. If you can't steer, every number on screen has to explain itself.
The pacing has to feel alive without rewarding attention. Watching should be optional.
There's no failure state to design around. Just vibes and compounding interest.

It turns out watching numbers grow is surprisingly relaxing when you've accepted you can't do anything about it. It's the Bob Ross of incremental games.

The whole thing is AI-generated

I didn't hand-write the game logic. The entire app — the economy curves, the business names, the tick loop, the UI — was generated and then iterated on with an LLM in the loop. I gave it constraints ("no player input, must feel alive, numbers must compound believably") and let it cook.

This is part of a larger experiment: I run a little factory of these apps, each one generated and deployed on its own isolated Railway service. One app, one container, one subdomain. If a generation goes sideways, the blast radius is one silly game.

The tick loop is about as boring as you'd expect:

useEffect(() => {
  const id = setInterval(() => {
    setEmpire(prev => {
      const income = prev.businesses.reduce(
        (sum, b) => sum + b.rate * b.level * b.multiplier,
        0
      );
      return {
        ...prev,
        cash: prev.cash + income,
        businesses: maybeAutoUpgrade(prev.businesses, prev.cash + income),
      };
    });
  }, 1000);
  return () => clearInterval(id);
}, []);

The only "decision" the game makes is maybeAutoUpgrade — a tiny heuristic that reinvests cash into whichever business has the best ROI. It's a fake CEO running on a single setInterval.

Weird choices I'd defend in a code review

No persistence. Close the tab, lose your empire. This is a feature — it forces the app to be an experience, not an obligation. No FOMO, no save-scumming.
One service per app. Each silly thing I generate gets its own Railway deployment. Overkill? Absolutely. But it means I can nuke or redeploy one without touching the others, and cold-start cost is basically zero.
Client-only state. No backend. The economy lives entirely in React state. If you open two tabs you get two universes, which is philosophically correct for a game about doing nothing.

What I learned

When you take away interaction, UI design becomes really honest. Every pixel has to earn its place because the player has nothing to do except look at it. I ended up cutting about half the HUD I originally generated — the remaining half got better for it.

Also: generating small, weird apps and shipping each to its own isolated service is way more fun than maintaining one big monorepo of jokes.

Try it

Open the tab. Do nothing. Get rich (in fake money).

👉 lazy-tycoon.edgecasefactory.com

If you find yourself instinctively reaching for the mouse, congratulations — you've identified the problem the game is satirizing.

Show Dev: A boring corporate site hiding 30 easter eggs

Jean Michael Mayer — Thu, 23 Apr 2026 19:12:56 +0000

I built a website that looks like the most generic corporate homepage you've ever scrolled past. Stock photos of people in blazers shaking hands. "Synergy-driven solutions." A newsletter signup nobody asked for.

It's also hiding 30 easter eggs. Your job is to find them.

Why build a boring website on purpose

Most portfolio and marketing sites try to impress you in the first two seconds. Parallax, WebGL, a hero animation that eats your GPU. I wanted to do the opposite: build something so aggressively mid that your brain glazes over it — and then reward the people who poke at it anyway.

It's basically a love letter to the weird HTML comments, Konami codes, and hidden dev-console messages that used to be all over the web. The premise is simple: everything that looks suspicious probably is. Click the logo five times. Look at the page source. Read the 404 page carefully. Try entering up up down down somewhere.

The stack is dumb on purpose

This is a Next.js app deployed as its own service on Railway, sitting behind a subdomain of my side-project umbrella. No database. No auth. Progress is tracked in localStorage, which means yes — you can cheat, and I don't care.

The egg registry is a single typed object. Each egg has an id, a trigger, and a discovery payload. The UI subscribes to a global EggContext so anywhere in the app can fire a discovery:

const { discover, found } = useEggs();

<button
  onClick={() => discover("logo-clicker")}
  className="text-xl font-bold"
>
  MegaCorp Global Solutions
</button>

The context handles deduping, the toast animation, and persisting the found set. Adding a new egg is basically one entry in the registry plus a trigger wired up wherever it lives — a component, a keyboard listener, a route, a response header, whatever.

AI did most of the heavy lifting

I'll be honest: I did not hand-write 30 easter eggs and a full fake corporate site. The scaffolding, the filler copy ("Empowering tomorrow's tomorrow, today"), the stock-photo-shaped placeholders, the testimonials from "Jennifer, VP of Alignment" — all AI-generated, then curated. The eggs themselves were a back-and-forth: I'd prompt for a category (keyboard, DOM, network, cursor, timing) and pick the ones that actually made me smile.

This is where AI code generation shines, by the way. Not "build me a SaaS." More like "give me 10 weird but tasteful ways to hide a secret in a React page," then you, the human, act as the taste filter. The ratio was roughly 70% generated, 30% me fixing the three that didn't actually work and rewriting the jokes that weren't funny.

Edge cases I enjoyed

One egg lives in a custom HTTP response header. You have to open the Network tab.
One requires you to do nothing for 90 seconds.
One is in the robots.txt.
One involves the page title when the tab is backgrounded.
One is only reachable on mobile.

A few of them are genuinely mean. I'm sorry. Not that sorry.

Try it

Go hunt: easter-egg-excavation.edgecasefactory.com

Getting to 30 is harder than it sounds. If you find them all, the final screen is worth it — or at least, I think it is. Let me know in the comments how many you got without opening DevTools. No judgment if that number is zero.

Show Dev: I made a glassblowing sim you blow into

Jean Michael Mayer — Thu, 23 Apr 2026 15:21:56 +0000

Why blow into your laptop?

I've been building a series of tiny, weird web toys under the banner of "edge case factory" — apps that exist mostly because nobody asked for them. The latest one is Glassblower's Breath, a browser-based glassblowing simulator where you shape a virtual vase by literally exhaling into your microphone.

One breath. One vase. No undo.

The whole thing started from a dumb question: what if the input to a creative tool was something you can't really control precisely? Mouse input is too deliberate. Keyboards are too discrete. But breath? Breath is messy, noisy, and deeply analog. It felt like the right kind of input for molten glass.

Turning breath into geometry

The mic pipeline is embarrassingly simple. Grab an audio stream, run it through an AnalyserNode, and sample the low-frequency RMS to estimate breath intensity. Plosives and speech get filtered out by looking at spectral flatness — breath is broadband noise, speech has formants.

const ctx = new AudioContext();
const source = ctx.createMediaStreamSource(stream);
const analyser = ctx.createAnalyser();
analyser.fftSize = 1024;
source.connect(analyser);

const buf = new Float32Array(analyser.fftSize);

function sampleBreath() {
  analyser.getFloatTimeDomainData(buf);
  let sum = 0;
  for (let i = 0; i < buf.length; i++) sum += buf[i] * buf[i];
  const rms = Math.sqrt(sum / buf.length);
  // map rms to radial displacement on the current vase ring
  return Math.min(1, rms * 8);
}

Each frame, the current "ring" of the vase (it's built bottom-up, lathe-style) expands proportional to your breath. Stop breathing and the ring sets. The next ring starts slightly above. After ~15 seconds you've got a silhouette that's unmistakably yours — shaky inhales become pinched necks, a strong exhale makes a bulb.

The mesh is a revolved spline in Three.js with a refractive shader that cheats hard: a cubemap of a studio environment, a fresnel term, and some chromatic aberration on the edges. It's not physically accurate glass. It looks like glass from across a room, which is all you need.

Why it lives on its own Railway service

This app was almost entirely AI-generated — I scaffolded it by describing the behavior I wanted and iterating on the shader and the breath-detection heuristics. That workflow produces code fast, but it also produces code I don't fully trust to share a process with anything important.

So every edge-case-factory app gets its own Railway service on its own subdomain. Isolated deploys, isolated dependencies, isolated blast radius. If glassblowers-breath leaks memory or the shader pins a GPU somewhere, it doesn't take down the neighbors. Each app is a Next.js project with essentially zero shared code — I gave up on the monorepo dream after the second app.

The tradeoff is obvious: more services, more cold starts, more dashboards. The upside is that I can ship a weird thing in an afternoon and genuinely not care if it catches fire at 3am. For toys, that calculus is correct. For a real product, it wouldn't be.

The one UX decision I'm proud of

There's no "try again" button during a blow. Once you start, you're committed for the full duration. You can save the result or discard it, but you can't pause mid-breath to reconsider. This is annoying. It's also the entire point — real glassblowers can't pause either. The constraint is the feature.

Try it

Put on headphones (mic feedback is real), find a quiet room, and make a vase with your lungs:

👉 glassblowers-breath.edgecasefactory.com

If you make something beautiful or cursed, I'd love to see it.

Show Dev: I turned screen time reports into 3D trophies

Jean Michael Mayer — Mon, 20 Apr 2026 16:45:16 +0000

The itch

I was doom-scrolling at 1am, and iOS politely informed me I'd spent 4h 12min on Reddit that day. Instead of, you know, changing my life, I built an app that makes fun of me for it.

The Feed Autopsy takes your screen time screenshot, has an AI gossip columnist read you for filth, and then mints a little 3D shame trophy you can spin around in your browser. It's therapy, but worse.

Why a gossip columnist?

Most "digital wellness" apps are insufferable. They chirp things like "You used your phone 23% more this week! Let's set a goal! 🌱" and I want to throw my laptop into the sea.

Shame, delivered with theatrical flair, works better on me. So the prompt doesn't ask for advice — it asks for dirt. The model plays a columnist who has seen your TikTok time and is now whispering about it at brunch. The tone constraint ended up being the hardest part of the prompt engineering: "mean but fun" is a narrow band. Too soft and it's a Hallmark card. Too harsh and it's genuinely upsetting at 2am.

The vision pipeline

Screen time reports are images, and the formats vary wildly (iOS, Android, different locales, people cropping weirdly). Instead of OCR + regex hell, I just hand the image to a multimodal model and ask it to extract structured JSON:

const res = await fetch("/api/autopsy", {
  method: "POST",
  body: formData, // the screenshot
});

const { apps, totalMinutes, roast, trophyPrompt } = await res.json();

The same call returns both the extracted data and the roast, which keeps latency down to one round trip. A second prompt generates a short trophyPrompt — a physical description of what the shame trophy should look like, based on the worst offender. ("A bronze thumb, calloused, mounted on a marble base engraved INSTAGRAM 2h 47m.")

The 3D trophy

The trophy renders with react-three-fiber. I'm not generating mesh geometry from scratch — that way lies madness. Instead I have a small library of base trophy shapes (pedestal, plaque, figure slot) and the AI's description drives materials, colors, engraved text, and which figure sits on top. It's basically a Mad Libs for 3D.

You can drag to spin it. That's the whole feature. It is deeply unserious and I love it.

Why its own Railway service?

The main site is a Next.js app, but Feed Autopsy runs as an isolated service on Railway with its own subdomain. Two reasons:

Blast radius. Image uploads + LLM calls + occasional 3D asset generation is a different risk profile than my blog. If someone figures out how to make it expensive, I want to kill that service, not the whole house.
Cold start honesty. Each experiment gets its own container, its own logs, its own budget alarm. When I inevitably abandon it in six months, I can nuke it without touching anything else.

Each app in my little factory of weird projects is deployed this way. It's more infra than a monorepo on Vercel would be, but it's made me way more willing to ship dumb ideas, because dumb ideas can't hurt the smart ones.

Try it

Upload a screen time screenshot. Get roasted. Keep the trophy.

👉 feed-autopsy.edgecasefactory.com

No signup, no email capture, no "premium tier." Just vibes and mild psychological damage. Tell me what the columnist said about you — I want to know if it's landing or if I need to make it meaner.

Show Dev: I Built a Dither Oracle That Roasts Your Soul

Jean Michael Mayer — Mon, 20 Apr 2026 16:31:14 +0000

The problem: I can't decide what to eat for lunch

I have a well-documented inability to make small decisions. Big ones I'm fine with — career moves, moving countries, sure. But "Thai or Vietnamese?" at 12:47pm? I will stand in the middle of the sidewalk until I dissolve.

So I built The Dither Oracle. You roll some dice, it gives you an answer, and then — because an answer alone is not enough for anyone in 2025 — it generates a dithered, black-and-white "soul portrait" to accompany the verdict. It's marketed, per the website, "AS SEEN ON TV!" It has not actually been seen on TV.

Why dithering?

Because color is a commitment and I am already paralyzed enough.

More seriously: dithering is one of those aesthetic constraints that makes cheap things look intentional. A crisp 1-bit image with Floyd–Steinberg or Atkinson diffusion has this early-Macintosh, zine-photocopy energy that masks a lot of sins. Including, say, the sins of a generative model that occasionally produces sixth fingers.

The pipeline is roughly:

User rolls dice → seed + vibe string
Prompt gets assembled and sent to an image model
Image comes back, gets downscaled and quantized to 1-bit
Error-diffusion dither on a Canvas, then blitted to the page

The dithering itself runs client-side. There's no reason to pay for CPU cycles to push pixels around when the user's laptop is sitting there idle.

async function rollOracle(dice) {
  const res = await fetch("/api/oracle", {
    method: "POST",
    body: JSON.stringify({ dice, seed: crypto.randomUUID() }),
  });
  const { verdict, imageUrl } = await res.json();
  const bitmap = await loadImage(imageUrl);
  return { verdict, pixels: atkinsonDither(bitmap, { threshold: 128 }) };
}

The weird infrastructure choice

The Oracle lives in its own Railway service, separate from the rest of my apps. This was not the plan. The plan was "throw it on the same Next.js app as everything else."

But image generation is bursty and slow. A single roll can tie up a request for 5–15 seconds waiting on the model. If I colocate that with a normal webapp, one viral tweet means everybody's unrelated dashboards start timing out because the Node process is babysitting dice rolls.

So: isolated service, its own queue, its own env, its own crash radius. When the Oracle falls over (and it does — models hiccup, rate limits happen), the blast zone is exactly one dumb dice app. The main site stays up. This is the boring-but-correct answer nobody tells you at the start of a side project, and I only learned it after the third time I DDoS'd myself with my own hobby traffic.

On letting the AI be weird

I had a choice: tightly constrain the prompts so the output is "on brand," or leave enough slack for the model to surprise me. I went with slack. The Oracle's verdicts range from gently encouraging to mildly menacing, and the portraits are sometimes a crow, sometimes a hand holding a peach, sometimes a geometry problem. That variance is the product. A deterministic oracle is just a function. An unpredictable one is a bit.

The dither pass flattens all of this into the same aesthetic register, which is the other reason I chose it. No matter how feral the model gets, it comes out looking like it belongs on a flyer stapled to a telephone pole in 1994.

Try it

Roll the dice here: dither-oracle.edgecasefactory.com

It's free. It's fast. It will tell you whether to text them back. I take no responsibility for the outcome.

Show Dev: A Dragon That Burns Your Village If You Misspell

Jean Michael Mayer — Sun, 19 Apr 2026 20:35:05 +0000

The pitch

I built The Dragon's Dictionary: a bilingual (English/Portuguese) word game where a hoarding dragon eats words you feed it. Spell them right, the dragon is pleased and adds them to its hoard. Spell them wrong, and it torches your village.

It started as a joke about how Duolingo's owl is menacing but polite. I wanted something that felt genuinely unhinged — a creature that cares more about its word collection than your feelings.

Why a dragon, why two languages

I'm learning Portuguese. Most vocab apps treat bilingual learners like monolinguals who happen to own a dictionary. I wanted a game where switching languages mid-session is the point, not a settings toggle buried three menus deep.

The dragon also solves a UX problem I keep hitting with language apps: stakes. Flashcards have no stakes. A burning village has stakes. The cognitive load of "don't kill the villagers" turns out to be a surprisingly effective mnemonic device.

The weird technical choices

It's almost entirely AI-generated. Not "AI-assisted" — I mean the dragon's reactions, the villager names, the insults it hurls when you fail, are generated on demand. I keep a small corpus of base words and let the model riff on reactions per session. This is why the dragon feels inconsistent in a charming way: it is inconsistent.

It runs in its own Railway service. I have a small constellation of side projects under edgecasefactory.com, and I used to cram them all into one monorepo behind one Next.js deployment. That was a mistake. One project's dependency bump would break two others. Now each dragon, factory, and whatever-else gets its own Railway service with its own lifecycle. Deploys take 40 seconds and I stopped dreading npm update.

No database for game state. The dragon's hoard lives in localStorage. I considered Postgres, Redis, SQLite-on-a-volume, the works. Then I remembered this is a game about a dragon and nobody needs their village-burning history to sync across devices. Deleting the database was the single best architectural decision I made.

The scoring loop

Here's the core validation call. The model grades the word, returns a reaction, and decides the dragon's mood:

async function feedDragon(word, lang) {
  const res = await fetch('/api/feed', {
    method: 'POST',
    body: JSON.stringify({ word, lang, hoard: getHoard() })
  });

  const { valid, reaction, mood, villagersLost } = await res.json();

  if (valid) {
    addToHoard(word);
  } else {
    burnVillage(villagersLost);
  }

  return { reaction, mood };
}

The server-side check does two things: a dictionary lookup (cheap, deterministic) and an LLM call for the reaction text (expensive, flavorful). If the LLM times out, the dragon just grunts. Graceful degradation, dragon-style.

What surprised me

Portuguese has a lot of accented characters that are easy to get wrong on a US keyboard. I ended up adding a "close enough" mode because forcing learners to type ção correctly on first try felt more like a bureaucratic form than a game. The dragon now accepts cao but makes fun of you for it.

Also: players burn their own village on purpose. A lot. I did not design for this. I now embrace it.

Try it

🐉 dragons-dictionary.edgecasefactory.com

Feed the dragon. Don't feed it gibberish. Or do — the villagers signed waivers.

Feedback welcome, especially from Portuguese speakers who want to tell me my conjugation tables are wrong.

Show Dev: Your Face Is Now a Music Generator

Jean Michael Mayer — Sun, 19 Apr 2026 19:27:43 +0000

The Dumbest Idea I've Shipped This Month

I built a thing called The Mood Ring Playlist. It points your webcam at your face, reads your emotions, and generates a live music track that shifts as you do.

Smile? Tempo kicks up, major key, bright pads. Scowl at your code review? Minor key, slower, a little more low end. Zone out completely? It drifts into ambient territory.

This article is the "why would you do this" post, plus a couple of technical choices that turned out weirder than I expected.

Why Build This

I wanted to play with two things at once: browser-based face detection and procedural audio. Every "AI music" demo I've seen is either:

Generate a 30-second clip, wait, listen, regenerate.
Upload a giant model to the browser and pray the user's laptop doesn't melt.

I wanted something continuous. Not "click to generate a song" but "the song is you, right now." That framing changed every architectural decision.

Face In The Browser, Music On The Server

Face detection runs entirely client-side. Webcam frames → face landmarks → a small vector of emotion probabilities (happy, sad, angry, surprised, neutral, etc.). None of that leaves your machine. This is both a privacy win and a latency win — I don't want to ship webcam frames across the internet just to find out you're mildly annoyed.

The music generation, though, lives in its own Railway service. That was deliberate. The main Next.js app is a thin frontend. The generator is a separate long-running Node service that holds state, manages the synthesis graph, and streams parameter updates based on the emotion vector it receives.

Why split it?

Cold starts would kill the vibe. Serverless functions booting mid-song is not a vibe.
It's stateful. The generator needs memory of what was just playing so transitions don't sound like someone slapping the radio dial.
I can redeploy the UI without killing the audio.

The client just posts emotion snapshots and receives back instructions for what the Web Audio API should do next.

useEffect(() => {
  if (!emotions) return;
  const id = setTimeout(async () => {
    const res = await fetch('/api/mood', {
      method: 'POST',
      body: JSON.stringify({ emotions, t: performance.now() }),
    });
    const { tempo, key, layers } = await res.json();
    mixer.current?.update({ tempo, key, layers });
  }, 250);
  return () => clearTimeout(id);
}, [emotions]);

That 250ms debounce matters. Early versions updated every frame and the music sounded like a panic attack. Humans don't actually change mood 60 times a second — who knew.

The AI Part, Honestly

The "AI" here isn't a giant model generating waveforms. It's a smaller system that maps an emotion vector to musical parameters: scale, tempo range, instrument layer weights, chord progression tendencies. Think of it as a learned policy over a procedural music engine, not Suno-in-a-box. That's how it stays real-time.

I tried the "just call a big model every few seconds" route first. It sounded great when it worked and terrible when it stitched. Seams everywhere. The procedural-with-a-smart-director approach wins because continuity matters more than novelty in ambient music.

Known Weirdness

If you wear glasses with heavy reflections, it thinks you're surprised a lot.
If you laugh hard enough to close your eyes, it briefly assumes you left.
Lighting matters more than I'd like. Sorry.

Try It

Give it your face for a minute. See what you sound like today.

👉 mood-ring-playlist.edgecasefactory.com

Headphones recommended. Webcam required. Judgment optional.