DEV Community: On Pounch Man

I Built an AI Tarot Demo in Two Hours. Shipping the Product Was a Different Job.

On Pounch Man — Fri, 18 Sep 2026 09:59:28 +0000

My wife was interested in tarot cards, and I was a frontend developer looking for an excuse to build something. I put together a page with a deck, a card-flipping animation, and an AI-generated reading.

With AI assistance, the basic flow worked in about two hours.

I thought authentication and payments would get it ready to launch. Then the questions started: What happens when someone switches devices? What if a paid reading stops halfway through? Can I change a guided exercise without changing the meaning of someone’s saved answers?

Eventually, another question became harder than any of those: how do I get people to use it?

The project is now Mystic Journey. It includes a daily card ritual, guided explorations, a personal journal, and an optional companion board.

I’m still looking for early users. This is a development retrospective—and, openly, an invitation to try what I’ve built.

Why I changed the product

The original experience was straightforward: ask a question, draw cards, read the interpretation, leave.

But a general-purpose AI can already explain tarot cards. A nicer animation wasn’t enough to explain why someone should return to my website.

I started thinking about the experience around the reading. Writing in an empty journal can be surprisingly difficult. A card, a specific question, or a few choices might make it easier to begin reflecting.

That became the daily ritual: choose your mood, reveal your daily card, read a reflection prompt, and optionally write a few words. The aim is to make a small check-in easy, even when you don’t have a major question to ask.

For people who want to go further, I added six guided themes covering space, boundaries, change, confidence, connection, and direction. Each has five short chapters: notice the situation, consider another perspective, choose a small action, identify obstacles, and find support.

These explorations use curated branches rather than generating every step with AI. Earlier choices influence later options. Personal notes are optional and don’t automatically trigger a model call.

This gives me content I can review and improve consistently. Open-ended AI readings still have a place, but they don’t need to power every interaction.

Completed rituals, explorations, and explicitly saved readings go into a personal Journey timeline. The intention is to give people something worth revisiting: their own thoughts and choices, not just a list of cards.

I also added an opt-in weekly companion board. It shows names, avatars, and activity points, but not private reflections. Points are separate from purchases and don’t depend on someone’s mood or how much they write.

There’s a tension here: even a gentle leaderboard can create comparison. Whether it feels supportive is something I need users to tell me. These are product hypotheses, not proven retention improvements.

A small stack, with more state than I expected

The stack is Nuxt 3 for the statically generated frontend, a separate Fastify API, SQLite, and DeepSeek for generated readings. Nginx routes API requests to the backend.

For the current scale, I want something I can deploy and troubleshoot on my own. The difficult work has mostly been in the behavior of the application, not the number of services.

A daily card becomes account data once it connects to reflections, history, and rewards. Someone opening the site on their phone should see the same record they started on their laptop. Completion and rewards need consistent server-side state.

Disabling a button helps the interface, but it doesn’t prevent retries or requests from another tab.

Guided exploration saves have a similar problem. If a laptop has already saved the next chapter while a phone still has an older revision, accepting the phone’s write could overwrite newer progress.

Relevant save requests carry a revision. A stale write gets a conflict response, and the frontend keeps the draft while offering to reload saved progress. Identical committed retries return the existing result.

These are easy details to overlook when you only test one browser tab on a reliable connection.

The content needed versioning, too

One of the more interesting problems came from changing the exploration itself.

Suppose a saved answer says the user selected option 1. If I reorder the options next week, that stored value can appear to mean something different.

This is a simplified example of the problem:

Version 1, option 1: Take time to reflect privately
Version 2, option 1: Talk to someone you trust

The number didn’t change. The user’s apparent answer did.

An exploration therefore retains the content version it started with. Old option meanings need to remain stable, and the live chapter and saved recap need to interpret answers through the same branch logic.

Once copy gives meaning to stored answers, editing it is also a data-compatibility decision.

Weekly reflections brought another state problem. A generation request can time out, a retry can start, and the original request can finish late. Without a guard, that older result could overwrite the newer one.

The implementation uses a generation state, an expiring lease, and a version condition when writing the result. A short database transaction protects state changes; it doesn’t stay open while waiting for the model.

A paid AI request has more than two outcomes

The demo treated generation as success or failure. Streaming makes that less tidy: a request can return some text, stall, lose its client connection, or finish without usable content.

Deep readings use server-sent events. The server applies a timeout and attempts to cancel the upstream request if the client disconnects early. Only a complete successful result goes into the result cache.

If generation fails after credits have been deducted, the error path restores those in-app credits and provides a local card interpretation. Restoring credits is separate from refunding a payment through the payment provider.

Weekly reflections also have a model-call budget and a local fallback. A free feature still needs a cost boundary.

This isn’t a complete recovery system. For example, a process crash after a deduction cannot be recovered by a catch block in that same process. Durable job state and reconciliation remain areas to improve.

That distinction matters: having an error handler is not the same as having verified recovery from every failure.

Security extends beyond the prompt

The model generates text. It doesn’t decide account permissions, payment status, or credit balances, and it has no database or payment tools.

That limits the consequences of a manipulated response, but it doesn’t solve prompt injection. User input can still interfere with the intended task, and model output needs to be treated as untrusted content when it reaches the UI.

The service currently has request rate limiting, body-size limits, and account and credit checks before paid generation. These are basic controls, not a claim of comprehensive protection. IP-based limits have limitations, and input handling and output rendering require their own review.

For accounts, passwords use salted hashes, the database stores hashes of session tokens, and session cookies use HttpOnly and SameSite settings, with Secure enabled for production. Verification codes expire and have attempt limits.

Payments have a separate trust boundary. The backend confirms payment status with the provider and verifies webhook signatures. Order-status requests check ownership. Since polling and a webhook can both confirm the same payment, crediting an order must be idempotent.

Privacy also affects ordinary feature decisions. The feedback form doesn’t automatically attach someone’s journal entries. Analytics can record that a reflection was saved without collecting its text.

I still have security work to do. Keeping track of what each component can access—and where personal content goes—has been more useful than treating safety as a few lines in a system prompt.

Performance and localization added their own work

Static generation lets me serve public pages separately from account APIs, but it doesn’t automatically make the experience fast. Images, animations, authentication checks, and API latency still matter on a phone.

The Journey timeline is paginated, details load on demand, and uploaded avatars are cropped and compressed to WebP in the browser. Streaming also needs the proxy to cooperate: response buffering can hide the incremental output the server is sending.

The interface supports eight languages, while the card data is primarily English and Chinese, with English fallback elsewhere. Those are different levels of localization, and I shouldn’t present them as equivalent.

A recent bug was a good reminder of the extra surface area: an email placeholder contained a literal @, which the i18n message compiler interpreted as special syntax. The JSON was valid, but the page failed. A JSON parse check alone couldn’t catch it.

Even a small copy change needs the right kind of validation.

Shipping didn’t bring users automatically

I’ve shared the product on Solo, 出海栈, 小众软件, and Indie Hackers. That has given it places to be discovered, but I don’t yet have enough evidence to call any channel a repeatable source of users.

I’m also learning to separate people who enjoy a development story from people who want the product. Developers may find concurrency handling interesting. A potential user wants to know what they can do, how much effort it takes, and whether their writing stays private.

There’s overlap, but a well-read technical post doesn’t prove demand.

My next experiments are technical retrospectives like this one, short product demonstrations, and content built around concrete reflection scenarios. Search is another ongoing task: a readable sitemap and a renderable page are necessary pieces, but I still need public content that answers something people actually look for.

What I want to measure is the path after a visit: does someone complete a first ritual, continue to another exploration chapter, or return a few days later? Knowing where that stops should help me choose between improving the entry flow, the content, or the acquisition channel.

Writing more code is the comfortable option. It gives me a visible result. Asking someone to try the product can end with “I’ll take a look” and nothing else. I’m trying not to mistake the comfort of development for evidence that another feature is needed.

Where the project is now

Mystic Journey is still early. I’m looking for a small group of people willing to try it and tell me what feels useful, confusing, or unnecessary.

The daily ritual and guided explorations are free; deeper AI readings use credits. If tarot is unfamiliar, you can start with an exploration theme that fits something you’re thinking about.

Try Mystic Journey

Specific feedback would help most: where you got stuck, what didn’t make sense, or where you stopped wanting to continue. There’s a feedback form in the app, and comments here are welcome too.

If you’ve taken a side project beyond the demo stage, I’d also like to hear how you found your first users who came back.

I Built TGDown, a Chrome Extension for Downloading Telegram Web Media

On Pounch Man — Thu, 17 Sep 2026 03:17:08 +0000

I built TGDown, a Chrome extension that adds download controls for images and videos in Telegram Web.

The original product goal was simple: when users browse a Telegram chat, channel, or search result, they should be able to save media without repeatedly opening the viewer, fighting the context menu, or handling every item one by one.

The implementation was less simple.

Telegram Web is a large, fast-moving single-page application. An extension needs to add UI without breaking scrolling, media interactions, theme behavior, or Telegram's own event handling. This post is about the architecture behind TGDown — and a dark-mode bug that forced me to rethink how its in-page UI was mounted.

What TGDown does

TGDown supports both Telegram Web interfaces:

web.telegram.org/a/*
web.telegram.org/k/*

It provides:

One-click image and video downloads inside chats
Batch downloads from Telegram search results
A popup panel that lists detected media
Warnings for very large or long videos before a browser download starts
No separate TGDown account or subscription

The extension architecture

TGDown is a Manifest V3 extension built with TypeScript and Vue.

There are three execution contexts involved:

Content script

Runs alongside Telegram Web, watches the DOM for supported images and videos, and mounts download controls.
Page-context script

Some downloads need Telegram Web's existing authenticated browser session. Since a content script is isolated from the page's JavaScript context, TGDown injects a small page-context script and communicates with it through DOM events.
Extension pages

The toolbar popup is a Vue application. It lists media detected while browsing and can trigger a download from the active Telegram tab.

This separation keeps Telegram Web responsible for its own session, while the extension stays isolated from the application's internal code as much as possible.

The dark-mode white-screen bug

One of the most interesting bugs appeared only in Telegram's dark theme.

My first approach for modal-style UI used a full-screen iframe. The iframe had a transparent background, which seemed like a safe way to isolate extension styles from Telegram's styles.

In practice, it was not safe.

On a dark Telegram page, users would occasionally see the entire page turn white. It looked as if Telegram had failed to load, but the problem was the extension UI.

The sequence was roughly:

A full-screen iframe was inserted above Telegram.
The browser created the iframe document.
Before the iframe application had initialized — or when initialization failed — the iframe document rendered the browser's default page canvas.
That canvas was white, even though the iframe element itself was configured as transparent.
Because the iframe covered the viewport, it hid Telegram completely.

The bug was much easier to notice in dark mode because a white flash or white overlay has maximum contrast against Telegram's dark UI. In light mode, the same failure could be almost invisible.

The key lesson was simple:

A transparent iframe element does not guarantee a transparent iframe document.

The fix: Shadow DOM instead of a full-screen iframe

I removed the full-screen iframe from the Telegram page UI path.

TGDown now mounts its in-page controls in a Shadow DOM host. This preserves CSS isolation while avoiding a separate document with its own default rendering surface.

The host is also designed not to interfere with Telegram:

.tgdown-host {
  pointer-events: none;
}

.tgdown-host .download-button,
.tgdown-host .modal,
.tgdown-host .toast {
  pointer-events: auto;
}

The host itself ignores pointer events. Only actual TGDown controls opt back in, so Telegram remains clickable and scrollable everywhere else.

Keeping the integration conservative

Telegram Web has its own click handling, overlays, media viewer, and virtualized message list. A browser extension can easily become too aggressive: global CSS overrides, broad event listeners, or page-wide z-index layers may fix one download issue while breaking unrelated Telegram behavior.

TGDown takes a narrower approach:

It only targets supported media elements and its own controls.
It avoids replacing Telegram's global objects or fetch implementation.
It waits until Telegram has completed its initial page load before injecting behavior that depends on the page context.
It uses Shadow DOM rather than global CSS to isolate extension UI.
It keeps the UI non-interactive by default, enabling pointer events only for visible TGDown controls.

Telegram Web can still change its DOM structure, but keeping the integration narrow makes failures more contained and easier to diagnose.

Browser downloads still have limits

For regular images and videos, browser downloads work well. Larger media is different: browser memory, network stability, and the way Telegram Web exposes media URLs can affect reliability.

TGDown warns before especially large or long downloads, but leaves the final decision to the user.

Try TGDown

If Telegram Web changes and TGDown stops detecting a specific kind of media, feedback is welcome. The most helpful report includes the Telegram Web version (A or K), media type, and reproducible steps.

I Built TabScribe: A Free Chrome Extension to Copy All Browser Tabs as Markdown (Under 100KB, 12 Languages)

On Pounch Man — Sun, 07 Jun 2026 11:47:17 +0000

Why I Built TabScribe

After yet another research session where I found myself manually copying 20+ browser tab URLs one by one into my Obsidian notes, I decided enough was enough. I needed a tool that could copy all my tabs at once — in Markdown format.

I searched the Chrome Web Store. The existing options were either:

Too bloated (OneTab at 2M+ users, but does way more than I need)
Only supported plain text URL lists (Copy All URLs)
Abandoned for years (the old TabCopy extension)

So I built TabScribe over a couple of weekends.

What TabScribe Does

One click → all your tabs land in your clipboard in your chosen format:

Markdown [title](url) — perfect for Obsidian, Notion, VS Code
JSON array — great for data processing
Plain text — with custom delimiters
HTML unordered list — for web-based notes

Key Features

⚡ Keyboard Shortcut (Alt+Shift+C) — Copy all tabs without opening the popup

💾 Save & Restore Tab Groups — Save your tabs as named groups locally. Restore them in a new window later. Great for context switching.

📤 Export as Files — .md, .txt, .json, or .html with auto timestamps

🎯 Smart Filtering — Auto-excludes chrome://, edge://, about: pages. Optionally exclude pinned tabs.

🔧 Custom Delimiter — Set your own separator for text output (e.g., | for CSV-style)

🌐 12 Languages — English, 中文, 日本語, 한국어, Deutsch, Français, Español, Português, Русский, Bahasa Indonesia, and more

🎨 Dark Mode — Auto-follows system theme

Technical Deep Dive

Tech Stack

Preact + TypeScript + Tailwind CSS + Vite + crxjs
Bundle: ~63KB (gzipped: ~17KB)
Dependencies: 0 external runtime deps

I chose Preact over React deliberately. For a Chrome extension popup, every kilobyte matters. Preact's 3KB footprint vs React's 40KB+ is a no-brainer. Plus, with @preact/preset-vite, the DX is nearly identical.

The Clipboard Challenge (Manifest V3)

The hardest technical problem was clipboard access in Manifest V3's Service Worker context.

In MV3, the background page is replaced by a Service Worker — which has no DOM. The document.execCommand('copy') fallback doesn't work there. Here's my solution:

// Double-fallback clipboard strategy
async function copyToClipboard(text: string, html?: string) {
  // Strategy 1: Modern Clipboard API (works in popup + offscreen)
  try {
    const item = new ClipboardItem({
      'text/plain': new Blob([text], { type: 'text/plain' }),
      ...(html ? { 'text/html': new Blob([html], { type: 'text/html' }) } : {}),
    });
    await navigator.clipboard.write([item]);
    return;
  } catch { /* fall through */ }

  // Strategy 2: execCommand fallback (popup context only)
  if (typeof document !== 'undefined') {
    const textarea = document.createElement('textarea');
    textarea.value = text;
    document.body.appendChild(textarea);
    textarea.select();
    document.execCommand('copy');
    document.body.removeChild(textarea);
    return;
  }

  // Strategy 3: Chrome Offscreen Document (Service Worker context)
  await chrome.offscreen.createDocument({ /* ... */ });
  // Route clipboard write through the offscreen document
}

i18n Architecture

I used Chrome's built-in chrome.i18n API with 12 locale JSON files. The extension name and description in manifest.json use __MSG_key__ placeholders, so the Chrome Web Store automatically displays the right language.

// _locales/ja/messages.json
{
  "extensionName": { "message": "TabScribe" },
  "extensionDesc": { "message": "すべてのタブをMarkdown/JSON/HTMLで一括コピー" }
}

Privacy by Design

TabScribe collects zero data. Period.

No analytics
No tracking pixels
No external servers
No network requests (except extension updates from Chrome)
Everything stored in chrome.storage.local

Only 6 permissions requested, each with a clear purpose:

Permission	Why
`tabs`	Read tab titles & URLs
`clipboardWrite`	Copy formatted text
`storage`	Save preferences & tab groups locally
`commands`	Register keyboard shortcut
`downloads`	Save exported files
`offscreen`	Clipboard access in Service Worker

Try It

🔗 TabScribe on Chrome Web Store

It's free. No signup. No tracking. Just productivity.

Built with Preact + TypeScript + Tailwind CSS. Source code available on GitHub.