Personalized playable games,
certified yours.

Make it about someone they love — then let them play.

The same emotional trick JibJab monetized, upgraded from watch-once to play-many.

JibJab turned "put your face on a dancing elf" into a recurring holiday habit worth a reported eight figures a year. We do the same trick — personal, funny, about someone specific — but the output is a playable game. Playing beats watching on every metric that matters: dwell time, replays, competition, and the reason to send it back.

We already own the two hard pieces. GenieMade is a certified AI image/video engine with credits, R2 storage, a paywall, and a provenance moat. DreamAuthentics is a skinnable game engine that already runs from a 30-second whack game to a full Centipede clone. Games are simply the third creation type that fuses them — not a new product, a new type on an engine that exists.

The first game is already live at partypop.pages.dev — built on our own Cloudflare, personalized from 3 uploaded photos in about 30 seconds.

A video is finished when you watch it. A game asks you to do something.

And "do something" is where re-shares and account creation come from.

Games are a new type on the engine you already have.

Grounded in your real seam — pcos-geniemade-vault-code. We extend it; we don't build a parallel engine.

Your GenieMade engine already does POST /api/generate {type, references} → quota → fal → R2 → SHA-256 certificate → credits, with a paywall and a gallery. Games add one value of type:

# the ONE new creation type — everything else is reused
POST /api/generate
  { type: "game",
    template: "whack-a-wish",        // which mechanic + occasion
    subject:  { name, age|occasion },
    references: [face1, face2, face3] }   // the 3 photos
  →  1. (optional) fal: cut-out + toon each face  → sprite set
     2. assemble SKIN PACK → R2 (geniemade-assets/skins/<id>)
     3. persist instance → KV: { id, template, skinKey, subject }
     4. SHA-256 certificate + provable-chain append  ← existing moat, now on games
     5. → { play_url: "/play/<id>", certificate, credits_remaining }

Everything reused: credits, R2 storage, the certificate/provenance chain, the 402 paywall, the gallery. The site adds two routes — /play/<id> serves the shared static game engine and the skin loads from /asset/skins/<id>; /g/<id> is the share page whose preview image is the star's face. Nothing new in the stack — it's the Cloudflare Pages + Worker you already run.

10×–20× titles from a grid, not a list.

Ship the mechanics once; re-skin them across the calendar. 7 engines × 16 occasions = 112 possible titles.

We don't build 112 — we launch ~15 flagship cells timed to the send-volume spikes (Birthday, Christmas, Valentine's, Halloween first), then add a cell as each holiday approaches. That's the 10×–20× catalog for a fraction of the build.

Simple → arcade, one engine. We already own both ends.

A video-only competitor can't follow us up the complexity curve.

Both tiers consume the same skin pack, so a customer can start with a 30-second whack game and upsell into a premium arcade title for the same person — no new art. Already built & reusable: Whack-a-Wish (whack), Crawler (Centipede), DreamDrop (Kaboom/catch), each with the skin-layer system.

Freemium credits — the free tier is the ad.

This is a healthier cost curve than a pure AI-video product where every output costs money: our free tier is cheap to run, and fal spend sits behind the paywall where revenue already is. Plus a JibJab-style annual pass — theirs is unlimited cards, ours is unlimited games.

The viral loop is built into the mechanic.

A makes a game for B  →  B plays it (personal, fun)  →  B beats / shares the score
   →  every screen ends on "make one for someone"  →  B makes one for C  →  …

Two levers we control: the share card / clip carries the face (irresistible open-rate in a group chat), and the end-of-game CTA is a maker button, not a "learn more." We instrument K-factor from day one — the whole model lives or dies on it, so it's the first thing we measure.

Engine first, together. Deploy to GenieMade after.

Just the two of us build the engine now; we bring the GenieMade agents in only to deploy it into geniemadeit.com.

1. Phase 0 — the live proof DONE

   Whack template, 3-photo upload, personalized play, share card — on our Cloudflare.

2. Phase 1 — the unified engine NOW · you + me

   One repo, one engine core + skin-pack format spanning simple→arcade. Fold the prototype in beside Crawler/DreamDrop. Add client-side video capture (the JibJab-parity clip).

3. Phase 2 — the template library

   AI-toon face step (fal cut-out/stylize) + 3 more flagship templates (Cake Catch, Christmas Presents, Valentine Heart Pop) + watermark/paywall hooks.

4. Phase 3 — arcade tier + video

   Candle Centipede (skin of Crawler) as the premium "wow" title + HD gameplay-video render + gifting.

5. Phase 4 — deploy into GenieMade

   Now we bring the site/engine agents in: wire type:"game" into /api/generate, add /play/<id> + /g/<id>, certificate on games. It all lives inside geniemadeit.com — no separate brand.

Focused now, collaborative later.

They can copy a game. They can't copy "certified yours."

• "JibJab just copies us." They can clone a mechanic; they can't clone the provably-yours certificate — GenieMade already stamps every creation into a tamper-evident chain. "A personalized game that's certified yours" is a category they don't have.
• Likeness / kids' faces. Client-side-by-default (photos never leave the device on the free tier) is both a privacy selling point and a liability reducer; add consent + takedown on the paid/hosted tier.
• Content safety. The "roast" line needs guardrails (no harassment framing) — a moderation gate on hosted games.
• Seasonality. Revenue spikes on holidays; the mechanic-reuse model means we staff the calendar cheaply and always have the next holiday queued.