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

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)

1. Open TwitFlow.
2. Type a keyword, short phrase, or a short sentence you want to expand on.
3. Hit generate. AI returns five angles with short starter lines and a small engagement rationale.
4. 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

1. 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.

2. 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.

3. 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?