DEV Community: Lucas Zhuang

Building TwitFlow: Designing a 30-Second AI Spark for What to Tweet

Lucas Zhuang — Sun, 07 Jun 2026 13:47:19 +0000

Introduction

Coming up with something to tweet is an oddly common blocker. You know what you want to build, share, or teach, but when you open Twitter the cursor stares back at you. TwitFlow is a tiny product I built to remove that friction: a 30-second AI-powered spark that gives you angles, starter lines, and a place to stash local drafts.

In this post I’ll walk through the problem we solved, the product decisions that let us ship fast, the technical choices (Next.js, IndexedDB, Creem for one-time payments), and a few lessons learned that might help you ship similar micro-products.

The problem: blank-cursor syndrome

Many tools aim to make posting easier by handling scheduling, analytics, or multi-account publishing. Those problems assume the user already knows what to say. TwitFlow solves the step before that: "What should I tweet today?" The product is intentionally tiny: no account system, no Twitter API integration, and no server-side draft storage in the MVP. The goal was to get someone from blank page to a tweetable string in under 30 seconds.

Core product decisions

Focus: only solve "what to tweet". Not social management, not analytics.
No Twitter API. The Basic write permission is expensive and fragile; instead we copy-to-clipboard and open the compose URL. This keeps costs near-zero and avoids platform rate limits.
No account needed. Drafts live in IndexedDB. This removes signup friction and privacy concerns.
Monetization: free with ads + one-time $4.99 buyout to remove ads. No subscriptions in v1.

The minimal flow (30 seconds)

Open TwitFlow.
Type a keyword, short phrase, or a short sentence you want to expand on.
Hit generate. AI returns five angles with short starter lines and a small engagement rationale.
Save as a local draft and continue editing it if you want; when ready, copy the content and jump to twitter.com/compose/tweet to paste and publish.

Why these constraints? Speed and trust. By keeping everything local and lightweight we reduce user resistance. The product surface is small enough that people can try it in a single browser session without registering.

Architecture and tech choices

Frontend: Next.js (App Router). Familiar developer DX and Vercel deployment.
Styling: Tailwind + shadcn/ui for rapid UI iterations.
Local storage: IndexedDB via the idb wrapper for reliable, structured local persistence.
AI: a low-cost model (MiniMax M3 family in our stack) to balance quality and API cost.
Payments: Creem for one-time license key issuance. The flow issues a License Key by email; users paste it into TwitFlow to remove ads. The site verifies the key via a Creem license API and returns an HMAC-signed token stored in localStorage.

Small code example — generate endpoint (client side)

// client-side call to the generate API
async function fetchIdeas(keyword: string, language = 'en') {
  const res = await fetch('/api/generate', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ prompt: keyword, language }),
  });
  if (!res.ok) throw new Error('Generation failed');
  return res.json(); // { drafts: [{content, score, reason}, ...] }
}

Key trade-offs and why they matter

No account vs. no cloud sync: keeping drafts entirely local reduces friction and privacy risk. The trade-off is cross-device continuity — something we reserve for a future version once users ask for it.
No Twitter API vs. direct publishing: using copy-and-open keeps costs down and avoids API breakage, but it means TwitFlow can’t auto-post. For our target users (indie hackers and creators), copy+paste is acceptable and familiar.
One-time buyout vs. subscription: psychologically, a low one-time fee (e.g. $4.99) lowers the barrier for small wins. Subscriptions add churn pressure and require more features to justify recurring cost.

Product iteration and lessons learned

Ship narrow: the clearest feedback came from people who used TwitFlow as a single-purpose tool. Raising scope too fast dilutes the value proposition.
Local-first storage is a feature: users appreciate that their drafts are private by default. When we later considered cloud sync, retention metrics were already decent without it.
Offer multiple angles, not polished long tweets: users prefer a starter idea they can adapt to their voice rather than a fully written tweet that feels "AI-generated".
Small UI niceties matter: instant copy-to-clipboard, clear save icons, and an obvious path from idea → draft → tweet make the 30-second promise believable.

Challenges we faced

Payment verification UX: Creem returns license keys via email. We added a short path for users to paste keys into the product. To avoid lost keys or repeated activations, /api/activate validates keys and returns a signed token the client stores.
Pricing uncertainty: deciding between $4.99 and $9.99 was delicate. We launched with $4.99; early conversion data is the true judge.
Multi-language prompt tuning: supporting Japanese, Korean, Portuguese, and Spanish required localized prompt templates more than new models. That was cheap to implement but still required native review.

Roadmap highlights

Short-term (v1.x): improve prompts, add "quote mode" (give angles for replying/quoting an existing tweet), and polish the buyout flow.
Medium-term (v1.3+): optional account + cloud sync, a lightweight queue/ scheduler (local-first), and small analytics for local insights (which drafts users actually post).
Long-term (v2.0): browser extension and optional cross-device sync for users who want it.

How you can try or reuse parts

If you want to reproduce the core idea: a tiny UI + an AI endpoint + local IndexedDB storage is all you need. The UX is the product: fast, single-purpose flows win.
Use an inexpensive LLM for drafts (cheap model + tight prompt engineering). Store drafts locally and use the twitter.com/compose/tweet compose flow for publishing.

Closing thoughts

Micro-products can win by solving the single smallest friction in a larger workflow. TwitFlow’s job isn’t to replace publishing tools — it’s to make the first 30 seconds count. Keep the tool tiny, private by default, and optimize for the single ritual you expect users to repeat.

If you’re curious, I can share the exact prompt patterns and the /api/activate snippet that validates Creem license keys. Want those in a follow-up post?

How I Built an AI Emoji Generator with Next.js 15 & Cloudflare Workers AI

Lucas Zhuang — Sat, 09 May 2026 08:14:26 +0000

Every emoji tool I could find did the same thing: let you pick from a fixed set of combos.

Emoji Kitchen has 50K+ monthly visitors exactly because people love emoji combinations. But it's just a lookup table — Google pre-rendered ~40,000 combinations and serves them as static images. There's no AI, no creativity, no support for combinations that don't exist in the dataset.

I wanted to build something different: type two emoji, get a brand-new AI-generated image that's never existed before, with a transparent background so you can actually use it anywhere.

Here's how Forgemoji works under the hood.

A quick note on scope: I'm a UI/UX designer by trade, so I handled the full product — interface design, interaction design, and the engineering. The stack choices below reflect someone who thinks in user flows first and infrastructure second.

The Architecture: Three Layers

I ended up with a three-layer generation system, each progressively more capable (and more expensive):

Layer 1 — Static lookup     ← REMOVED (copyright risk)
Layer 2 — Text-to-image     ← Primary path (free, ~30s)
Layer 3 — Image-to-image    ← Upload your photo, fuse it with an emoji (~120s, async)

Layer 1 was the original plan — use Google's pre-rendered emoji kitchen images. I killed it on day 5 after reading Google's image attribution policy more carefully. The risk wasn't worth it.

Layer 2: Text-to-Image with a Provider Fallback Chain

The core challenge with T2I emoji generation is: how do you make the model output something that actually looks like an emoji?

The naive approach — "🐱 + 🔥" — produces whatever the model thinks a cat fire is. Usually it's a realistic cat on fire. Not what you want.

Prompt Engineering: Descriptions > Unicode

I built a mapping table (emoji-prompt-map.ts) that translates emoji into concrete visual descriptions:

const EMOJI_DESCRIPTIONS: Record<string, string> = {
  '😀': 'round yellow face, wide open grin showing teeth, simple oval dot eyes',
  '🔥': 'bright orange and red flame, cartoon style, rounded base',
  '🐱': 'cute round cat face, large eyes, small pink nose, whiskers',
  // 200+ entries...
}

Then the full prompt looks like:

function buildLayer2Prompt(emoji1: string, emoji2: string): string {
  const desc1 = EMOJI_DESCRIPTIONS[emoji1] ?? emoji1
  const desc2 = EMOJI_DESCRIPTIONS[emoji2] ?? emoji2
  return [
    `A single emoji character that fuses: [${desc1}] merged with [${desc2}].`,
    'Flat cartoon illustration style. Centered on pure white background.',
    'One single character only, no text, no multiple objects side by side.',
    'Clean vector-like look, bold outlines, vivid saturated colors.',
  ].join(' ')
}

The "one single character only" constraint is critical. Without it, models love to render two separate objects next to each other — a cat on the left, a flame on the right — which defeats the whole point.

The Provider Chain

No single free provider is reliable enough to use alone. I set up a priority fallback chain:

T2I: Cloudflare Workers AI (flux-1-schnell)
       → ModelScope Z-Image-Turbo
         → MiniMax image-01

Cloudflare's Workers AI gives ~230 free generations per day. For a bootstrapped side project, that's more than enough to handle organic traffic without paying anything. When it's exhausted or errors out, the request automatically falls to the next provider.

// Simplified provider selection
async function generateImage(opts: GenerateOptions): Promise<string> {
  const providers = isI2I(opts)
    ? ['gemini-proxy', 'gpt-proxy', 'modelscope-i2i', 'minimax-i2i']
    : ['cloudflare', 'modelscope-t2i', 'minimax-t2i']

  for (const provider of providers) {
    try {
      return await callProvider(provider, opts)
    } catch (err) {
      logProviderError(provider, err)
      // try next
    }
  }
  throw new Error('All providers failed')
}

Each provider failure fires a Discord webhook alert, so I can see in real time if a provider is down.

The Transparent Background Problem

This is where most emoji tools stop. They return a white or colored background, which makes the result useless for Discord stickers, Telegram emoji, or overlay use.

I run every generated image through rembg, hosted on my own server:

async function removeBackground(imageBase64: string): Promise<string> {
  const response = await fetch(process.env.REMBG_API_URL!, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-API-Key': process.env.REMBG_API_KEY!,
    },
    body: JSON.stringify({ image_base64: imageBase64 }),
  })
  const { result } = await response.json()
  return result // base64 PNG with alpha channel
}

But here's the UX problem: rembg takes 2–4 seconds. If you wait for it before showing anything, the whole generation feels slow.

Solution: Show the image immediately with the background, then swap to the transparent version once rembg finishes. The user gets visual feedback fast, and the "better" version appears a few seconds later without any loading state.

// In the API route: fire rembg async, don't await it before responding
const rembgPromise = removeBackground(rawImageBase64).catch(() => null)

// Return raw image first, rembg result comes via a separate /api/rembg call
// triggered client-side after the initial image loads

Layer 3: Image-to-Image (Upload Your Face)

The I2I mode lets users upload a photo and fuse it with an emoji style. This is the "Genmoji" experience — without requiring an Apple device.

The challenge here is latency. I2I models take 60–120 seconds. A synchronous API call times out on Vercel (max function timeout is 300s, and 120s is cutting it close).

I solved it with a submit/poll architecture:

POST /api/generate/submit  →  { task_id }
GET  /api/generate/poll?id=xxx  →  { status: 'pending' | 'done' | 'error', result? }

The client submits the job, gets a task_id, then polls every 3 seconds until done. The UI shows a countdown timer so users know roughly how long to wait.

For I2I, prompt engineering gets trickier. The model needs to clearly understand which elements to keep from the photo (the person's face) and which to replace with emoji style. I use a "dual prompt" strategy:

function buildLayer3DualPrompt(userEmoji: string, photoContext: string): string {
  const emojiDesc = EMOJI_DESCRIPTIONS[userEmoji] ?? userEmoji
  return [
    `Transform the person in the photo into a single emoji character.`,
    `Emoji style: ${emojiDesc}.`,
    `Keep the person's facial features and expression. Apply flat cartoon illustration style.`,
    `Result must be ONE centered emoji character. No background, no text.`,
  ].join(' ')
}

Rate Limiting Without a Database

I didn't want to add a database just for rate limiting. Solution: IP-based limits stored in a Vercel KV-compatible in-memory map (good enough for the current traffic level, will migrate when needed):

5 generations per IP per day
3 generations per IP per minute (burst protection)
500 total generations per day across all users

// In-memory store — resets on each Vercel function cold start
// Good enough for <1K daily users, not suitable for horizontal scaling
const ipDayMap = new Map<string, number>()
const ipMinuteMap = new Map<string, number>()
let globalDailyCount = 0

Is this production-grade? No. But for a side project at <500 daily users, it works perfectly and avoids adding infrastructure complexity before you need it.

The Animated Emoji Feature

Static emoji are fine. Animated emoji are shareable.

I added 6 preset animations (Bounce, Float, Wiggle, Pulse, Rubber, Spin) using Canvas frame-by-frame rendering, then encoding to GIF or WebP.

The browser-side approach (gif.js) is the fallback — it works but is slow on low-end devices. The real implementation sends the PNG to my server and uses FFmpeg:

Client: PNG + animation_name + size + format
  → POST /api/animate (my rembg server also handles this)
  → FFmpeg palettegen + paletteuse with reserve_transparent=1
  → Return GIF / WebP bytes

For transparent GIFs (critical for Discord/Telegram stickers), the FFmpeg command is:

ffmpeg -i frames_%03d.png \
  -filter_complex "[0:v] palettegen=reserve_transparent=1 [p]; [0:v][p] paletteuse=alpha_threshold=128" \
  output.gif

Getting the transparency right took way longer than I expected. The reserve_transparent=1 + alpha_threshold=128 combination is the key — without both flags, you get either a black background or jagged edges.

What's Next

The tool is live at forgemoji.com — free to use, no account required.

Current stats after ~2 weeks:

261 pre-generated combo pages for SEO long-tail
3-provider T2I fallback chain (zero paid cost for up to ~230 daily generations)
Full animated export: 6 effects × 3 sizes × 2 formats (GIF/WebP)

Things I'm still working on:

AdSense monetization (applied, pending review)
Product Hunt launch (waiting for stable UV baseline)
More emoji in the mapping table (currently ~200 entries, want 500+)

If you're building something similar and ran into the same "how do I make AI output something that actually looks like an emoji" problem, I hope this helps. Happy to answer questions in the comments.