DEV Community: Mohan

Dollars and rupees without Stripe: what building Skill Exchange's checkout taught me (PayPal + UPI)

Mohan — Sun, 02 Aug 2026 19:45:22 +0000

"Just add Stripe" is the default advice for a solo dev who needs to charge money. It works right up until you're an Indian merchant trying to sell to a buyer in San Francisco and a buyer in Bangalore in the same afternoon — at which point you discover that a single provider can't actually do both, and the fix rearranges more of your code than you'd expect.

I hit this building Skill Exchange (a marketplace for reusable AI skills — link at the end). The marketplace itself isn't the point here; it's the harness I used to figure out how to take money from two people on opposite sides of the world without a US entity and without Stripe. These are the things I'd tell another dev before they start.

PayPal in India is cross-border only — so it can't serve your Indian buyers at all

The first assumption to kill: PayPal is not a domestic payment method in India. PayPal shut down India-to-India domestic payments in April 2021. What's left works only cross-border — an Indian merchant can receive money from abroad, but a rupee-holding buyer in India cannot pay an India-based merchant through it.

I learned this the way you'd expect: I wired up PayPal, tested it with my own (Indian) account against my own (Indian) merchant account, and got a cheerful, useless "Things don't appear to be working at the moment." No error code, no docs entry — the transaction is simply classified as domestic and refused. It works flawlessly the moment the buyer is international, which is exactly what makes the failure so confusing when you're testing from your own country.

Takeaway: if any of your buyers are in the same country as your PayPal merchant account, PayPal alone will strand them. You need a second rail.

You need two providers, and the split is by currency, not features

So the architecture is two providers, chosen by the buyer's currency:

International buyers → PayPal, charged in USD.
Indian buyers → Razorpay, charged in INR via UPI (one-tap, near-zero friction, far higher conversion than cards in India).

The important design decision is that the buyer chooses the rail, at checkout, by choosing a currency. I default the toggle by timezone and let them override it — no IP lookup, no external call:

const defaultCurrency = (() => {
  try {
    const tz = Intl.DateTimeFormat().resolvedOptions().timeZone;
    return tz === "Asia/Kolkata" || tz === "Asia/Calcutta" ? "INR" : "USD";
  } catch { return "USD"; }
})();

A timezone heuristic is wrong for NRIs and travellers — which is exactly why it's only a default, never a lock. The toggle is always there.

Then the buy endpoint routes on that one field:

async function buySkill(user, skillId, body) {
  const skill = await getSkill(skillId);
  const wantsInr = String(body?.currency).toUpperCase() === "INR";

  if (wantsInr) {
    const paise = usdCentsToInrPaise(skill.priceCents);
    const order = await razorpay.createOrder({ amount: paise, currency: "INR",
      notes: { skillId, buyerId: user.id } });        // notes bind it to this buyer
    return { provider: "razorpay", orderId: order.id, amount: paise, currency: "INR" };
  }
  const order = await paypal.createOrder({ amountUsd: skill.priceCents / 100,
    skillId, buyerId: user.id });                     // custom_id binds it
  return { provider: "paypal", orderId: order.id, amount: skill.priceCents, currency: "USD" };
}

Don't show an exact FX conversion — round to local price points

The naive move is to convert the USD price at some rate and show the result. Don't. A $12 skill at ₹86/\$ is ₹1,032, which looks like a bug and feels expensive — Indian willingness-to-pay for digital goods is lower than a dollar conversion implies. Every serious seller into India uses regional price points instead.

So the conversion isn't usd * rate — it rounds to a familiar ₹x99:

const INR_RATE = 86; // one knob; change it to re-price the whole catalogue

function usdCentsToInrPaise(usdCents) {
  if (!usdCents) return 0;
  const rupees = (usdCents / 100) * INR_RATE;
  const clean = Math.max(1, Math.round(rupees / 100) * 100 - 1); // → ₹x99
  return clean * 100; // paise
}
// $5→₹399  $6→₹499  $9→₹799  $12→₹999  $15→₹1,299

That single INR_RATE constant re-prices 200+ listings at once, and the rounding doubles as a light purchasing-power discount without any per-item work.

Store the currency and the commission on the transaction — never recompute

This is the one that bites later if you skip it. The moment you have more than one currency (and a platform fee), you cannot derive money after the fact. Two rules:

Persist the currency on every purchase row. A bare amountCents is ambiguous the second some of them are paise.
Compute the platform commission at purchase time and store it. If your rate ever changes — mine went 10% → 5% — historical rows must keep the rate they were sold under. A commission you recompute on read is a commission you'll eventually get wrong.

purchase = {
  skillId, buyerId,
  amount: chargedMinorUnits,        // cents for USD, paise for INR
  currency,                         // "USD" | "INR"  — never omit
  commission: Math.round(chargedMinorUnits * 0.05), // frozen at sale time
  provider, providerPaymentId, purchasedAt: now,
};

And keep the seller-revenue aggregates per currency — summing cents and paise into one integer is how you produce a beautiful, meaningless number.

Verify the charge server-side against the order you created — not what the client says

Both rails let the browser lie to you, so the confirm step trusts neither the amount nor the "it succeeded" flag from the client. It re-derives the truth from the provider and checks it belongs to this exact buyer + item:

PayPal: capture the order server-side, require status === "COMPLETED", and check the custom_id you set at creation equals skillId|buyerId. A captured order can't be replayed against a different purchase.
Razorpay: verify the checkout HMAC signature, then fetch the order back and confirm its notes match the skill and buyer you created it for — the order amount/currency you record come from that fetch, not from the request body.

// Razorpay confirm
if (!verifyCheckoutSignature({ orderId, paymentId, signature })) return forbid();
const order = await razorpay.fetchOrder(orderId);            // source of truth
if (order.notes.skillId !== skillId || order.notes.buyerId !== user.id) return forbid();
await recordPurchase({ ...order fields..., currency: order.currency, amount: order.amount });

The rule is the same on both: the amount and currency you write to your ledger come from the provider's record of the order you opened, cryptographically tied to the buyer — never from the client that's telling you it paid.

What I'd tell the next person

If a PayPal buyer and merchant share a country, PayPal strands them. Plan for a second rail from day one.
Route by currency, default it, and always let the buyer switch.
Convert to local price points, not exact FX.
Freeze currency + commission onto each transaction; aggregate revenue per currency.
Re-derive the charge server-side from the order you created, tied to the buyer. Trust the provider's record, not the client's word.

None of this is exotic — it's just the stuff nobody mentions when the answer is "add Stripe," and all of it is invisible until the first "Things don't appear to be working" from your own test account.

I built this while making Skill Exchange — a marketplace for reusable AI skills where every listing has to prove it works. Happy to answer payments questions in the comments.

Experiments with On-device AI — What building on Gemini Nano actually teaches you

Mohan — Fri, 17 Jul 2026 09:14:45 +0000

Chrome ships a real LLM inside the browser now — Gemini Nano, exposed through a handful of built-in JS APIs (LanguageModel, Rewriter, Proofreader, Summarizer, Writer). No API key, no network call, no per-token bill. It runs on-device, which sounds like a free lunch right up until you start building against it and discover that "on-device" changes almost every assumption you've built up shipping against OpenAI or Anthropic's APIs.

I spent the last stretch building a small Chrome extension (Quill — five writing tools, on-device AI only) as a testbed for exactly this. The extension itself isn't really the point here; it's the harness I used to find out what's actually different about building on a model that lives on the user's machine instead of yours. These are the things I'd tell another dev before they start.

There isn't one API — there's a task API and a fallback API, and you need both

Chrome exposes two layers: dedicated task APIs (Rewriter, Proofreader, Summarizer, Writer), each shaped around one job with typed options, and the general-purpose LanguageModel (the "Prompt API"), which you drive with a raw system prompt. They're gated by separate chrome://flags entries and roll out to stable independently — which means on any given real machine, some subset of them is enabled and the rest aren't.

Hard-coding against Rewriter alone means the feature silently stops working on any profile where only the Prompt API is on, or vice versa. The fix is a fallback chain per capability: try the dedicated API, and if it's unavailable, reconstruct the same task as a system prompt for LanguageModel.

async function doRewrite(sharedContext, text, lengthPref, variationHint) {
  const a = await avail('Rewriter');
  if (a !== 'unavailable') {
    const r = await Rewriter.create({ sharedContext, tone: 'as-is', length: lengthPref });
    try { return await r.rewrite(text, { context: variationHint }); }
    finally { r.destroy(); }
  }
  // Rewriter isn't enabled on this machine — do the same job via the Prompt API.
  const sys = `${sharedContext} Preserve the original meaning. Output only the rewritten text.`;
  return promptOnce(variationHint ? `${sys} ${variationHint}` : sys, text);
}

This roughly doubles the code per feature, and it's the difference between "works on my machine" and "works." Treat "the task API is enabled" as a runtime fact you check, not a build-time assumption.

"Unavailable" is a state machine, not a boolean

availability() doesn't return true/false — it returns unavailable, downloadable, downloading, or available. The first time I hit unavailable on a clean profile with the flags apparently on, I assumed it meant the API genuinely couldn't be reached from a content script's isolated world, and started building an offscreen-document relay to work around a permissions boundary that, it turned out, didn't exist. The actual cause: I'd toggled the flag but never restarted the browser, so Chrome was still running with the old flag state. unavailable and "you forgot to restart" produce an identical string.

Once you're actually in the downloadable or downloading states, create() takes a monitor callback that reports download progress — the first call to a newly-enabled API triggers a one-time model pull that can take a while, and if you don't wire this up, your UI just looks hung:

const opts = { sharedContext, tone: 'as-is' };
if (a !== 'available') {
  opts.monitor = (m) => m.addEventListener('downloadprogress', e => {
    showProgress(`Downloading model… ${Math.round(e.loaded * 100)}%`);
  });
}
const r = await Rewriter.create(opts);

Two takeaways: don't build a workaround for "unavailable" until you've confirmed it isn't just an unflipped flag or a pending download, and always assume the first real call from a fresh install is going to be slow.

The model is small enough that instructions aren't guarantees

Task APIs and the Prompt API both run a genuinely small model compared to what you're used to calling over HTTP. Concretely, that means:

Length and count instructions are approximate. Ask for "exactly one sentence" or "under 200 characters" and you'll get close, not exact, often enough that you can't display raw output where a hard limit matters — measure it in code and treat the model's attempt as a first draft, not ground truth.
"Give me three different versions" undersells how similar they'll be. A single call asking for 3 variants tends to return 3 variants of the same idea with light word-swaps. Better results come from three separate calls, each with an explicit instruction to lean a different direction (shorter, more formal, more casual) — treat variation as something you engineer via prompts, not something you request as a parameter.
Output language isn't implicit. Both LanguageModel and the task APIs accept expectedInputs / expectedOutputs with a languages array. Skip it and you get a console warning and (per Chrome's own docs) less reliable output attestation — it's a one-line fix that's easy to miss because nothing breaks without it, it just gets quietly worse.

const opts = {
  initialPrompts: [{ role: 'system', content: systemPrompt }],
  expectedInputs: [{ type: 'text', languages: ['en'] }],
  expectedOutputs: [{ type: 'text', languages: ['en'] }],
};

You can't build a CI pipeline that assumes the model exists

There's no Gemini Nano on a GitHub Actions runner, and probably not on your laptop today either unless you've already downloaded it. If your test suite needs a real model, you don't have a test suite — you have a manual QA checklist. The only way to get real coverage is to mock Rewriter / Summarizer / LanguageModel etc. as jsdom globals and run your actual, unmodified feature code against the mock.

That works, with one sharp edge: your mock has to vary its output the same way the real model does, or it'll hide bugs instead of catching them. I had a tone-variant generator that deduped near-identical outputs (a legit anti-repetition guard), tested against a mock that returned the same canned string regardless of which prompt it was called with. Every "generate 3 variants" test passed — with exactly one result, because the mock made all three collapse to the same dedupe key, and an assertion checking "got at least one result" didn't notice it got the wrong number. The mock's laziness happened to produce output that looked like success. Once the mock was made to vary its response per input (the same way any real generative model does), the test correctly started failing until the dedupe logic was actually right.

General rule: if a feature fans out into N distinct things, your mock has to be capable of returning N distinct things, or you're not testing the fan-out — you're testing that your code doesn't crash.

The browser boundary is real, even if your first guess about it is wrong

A content script — the code that runs on the page you're actually operating on — cannot navigate the tab to chrome:// URLs; that's Chrome policy, not a bug to route around. If part of your UX involves sending someone to chrome://flags to enable a capability, that navigation has to be requested from the extension's background service worker instead, via chrome.tabs.create or similar, triggered by a message from the content script.

// content script: can't navigate to chrome:// itself
chrome.runtime.sendMessage({ type: 'OPEN_FLAGS', flag: 'rewriter-api-for-gemini-nano' });

// background worker: can
chrome.runtime.onMessage.addListener((msg) => {
  if (msg.type === 'OPEN_FLAGS') {
    chrome.tabs.create({ url: `chrome://flags/#${msg.flag}` });
  }
});

This is the boundary I correctly suspected existed — the mistake earlier was assuming the availability check had a similar boundary when it didn't. Worth internalizing both halves: some restrictions on what a page-level script can do are real and permanent, and the fix is to hand the action to a more privileged context. Others are red herrings that look identical from the error message alone. The only way to tell them apart is to isolate the actual cause before you build the workaround.

None of this is Quill-specific — it's what building anything on Chrome's on-device AI actually involves, independent of what the feature does.

If you want to see where these came out the other end: Quill is five writing tools (rewrite, proofread, summarize, list/table, freeform compose) running entirely on Gemini Nano, free on the Chrome Web Store.

Building LaunchPad: one product brief, 42 launch channels, and the bugs that almost sank it

Mohan — Sat, 11 Jul 2026 15:01:25 +0000

Launching a Product: A Translation Problem

Launching a product is a translation problem. Hacker News punishes anything that smells like marketing. X gives you 280 characters. The Play Store gives you 30 for a title and 80 for the short description, and the Chrome Web Store will reject a keyword-stuffed name outright. Same product, fifteen dialects.

I kept paying that tax on my own extension launches, so I built LaunchPad: you write one product brief, and it drafts a native post for 42 channels — each in that channel's voice, with its real character limits enforced at generation time. It launched on Product Hunt this weekend. This post is about the parts that were harder than they looked.

The Stack

React 18 + Vite on AWS Amplify, Lambda + DynamoDB + API Gateway behind Cognito, Terraform for everything. The interesting choice is the AI layer: there isn't a server-side one. Drafting runs either on Chrome's built-in Gemini Nano (the Prompt API — free, on-device, nothing leaves your machine) or against the user's own OpenAI/Claude key, called directly from the browser. My servers never see a prompt, a draft, or a key. That's a privacy feature and a business model at once: my marginal cost per free user is roughly zero, so the entire product can be free for your first launch.

The Bug That Ate Every AI Draft

The editor is TipTap (ProseMirror). During generation, I lock each section by toggling setEditable(false). Drafts started vanishing: the AI would finish, the success toast would fire, and the editor would sit there empty.

The cause took a full evening: TipTap v3 emits update events for programmatic changes too. setEditable() and setContent() both fire the same onUpdate as a keystroke. So the lock itself triggered onChange('') — an empty "manual edit" that overwrote the freshly generated draft in the store, stamped manual provenance on it, and autosaved the damage.

The fix is a ref that marks self-inflicted mutations:

const applyingExternal = useRef(false);

onUpdate: ({ editor }) => {
  if (applyingExternal.current) return; // our own mutation, not the user's
  onChange(htmlToMd(editor.getHTML()));
},

useEffect(() => {
  applyingExternal.current = true;
  editor.setEditable(!readOnly);
  applyingExternal.current = false;
}, [readOnly]);

The general lesson: any rich-text editor's change event answers "did the document change?", not "did the user change it?". If you sync editor state to a store, you need to answer the second question yourself.

Stale Responses That Eat Local Edits

Twice — once for projects, once for preferences — I hit the same shape of bug: a GET fires on mount, the user makes a local change, the GET response lands after the change and replaces state wholesale. The user's brand-new custom channel just… evaporates. It surfaced as a flaky e2e test that only failed in-suite, which I almost retry-looped away before realizing the flake was the bug.

The guard is a version counter, not a lock:

loadPrefs: async () => {
  const ver = get()._prefsVer;
  const prefs = await api.getPrefs();
  if (get()._prefsVer !== ver) return; // a local write won the race — discard
  set((s) => ({ prefs: { ...s.prefs, ...prefs } }));
},
updatePrefs: (fields) => {
  set((s) => ({ _prefsVer: s._prefsVer + 1, prefs: { ...s.prefs, ...fields } }));
},

If your local state is the source of truth (it should be), a server response is a suggestion that expires the moment the user acts.

Character Limits: Models Can't Count

Every channel section carries its real limit — HN titles ≤80, Play Store short description ≤80, App Store keywords ≤100. Small on-device models blow past them constantly, and no prompt phrasing fixes it, because counting characters just isn't something a language model does reliably.

What shipped: the limit goes into the prompt ("HARD LIMIT … counting characters, not words — drop hashtags first"), the output gets measured in actual code, and there are up to two corrective retries that feed the overlong draft back with its measured length. Keep the shortest attempt. If it's still over, say so honestly — "Title is still over its limit, trim it by hand" — and paint the counter red. Users forgive a model that can't count; they don't forgive a tool that pretends it can.

Bulk Generation Is a Distributed System in One Tab

"Generate all 42" sounds like a for-loop. The for-loop version fails four ways:

One 429 killed the run. A rate limit on channel 9 abandoned channels 10–42. Now every channel runs regardless, outcomes are collected, and a report says 28 drafted · 1 failed (rate limit) · 2 skipped — and a failed channel keeps its previous draft and its provenance metadata untouched.
Nothing saved until the end. Autosave was debounced; 42 channels of continuous store writes reset the debounce forever, so a reload at channel 40 lost everything. Persistence now flushes after every channel.
No way out. Cancel now stops after the current section and keeps the finished work — "Cancel — keep what's drafted" — because the alternative reading of cancel (throw everything away) is never what anyone wants.
Toast spam. Leave the editor mid-run and each channel's success toast followed you around the app. During bulk runs, individual toasts are silenced; the report speaks once.

None of these showed up until a real user ran a real 42-channel generation with a real flaky key.

The Payment Bug: Your Email Is Not Your Identity

The webhook from my payment provider (Lemon Squeezy) identifies the buyer by email, so I resolved email → user and upgraded them. Tested it, worked, shipped it.

Then my own test payment upgraded… nothing I could see. The reason: one email can be several accounts. My address existed twice in Cognito — a Google-federated identity (my real login) and a native password user (the e2e test account). The Limit: 1 lookup upgraded whichever DynamoDB returned first, which was the wrong one. Any real user who'd ever signed in two ways would have paid and stayed on the free plan.

The fix is embarrassingly simple — update every account matching the payer's email — but the class of bug is worth internalizing: email is contact info, not a primary key.

While I was in there: subscription_cancelled means will not renew, not expired. Downgrading on cancel steals the month the customer already paid for. Keep the tier until the expired event arrives.

Two CSS Lines That Cost Half a Day Each

overflow-x: hidden on html, body — added innocently for mobile sideways-scroll protection — silently disables position: sticky everywhere. The spec-compliant fix is overflow-x: clip, which clips without creating a scroll container. My sticky top bar was broken for two deploys before anyone noticed.

And backdrop-filter on that same top bar creates a containing block: any position: fixed child gets trapped inside the bar's box. My ⌘K command palette rendered as a black strip inside the header and swallowed outside clicks until I portaled it to document.body.

The Regression Suite Is the Actual Product

The thing I'd defend hardest isn't a feature. It's the 21-test Playwright suite that runs against production — on every deploy as a release gate, and nightly on cron. Every bug a user reported this month became a permanent sentinel: security headers served, deep links returning real 200s (Amplify's SPA fallback quietly serves HTTP 404 on every route unless you add an explicit rewrite — renders fine, poisons link unfurlers), zero horizontal overflow at 390px, the sticky bar surviving a scroll, and the full OpenAI/Claude pipeline exercised with the provider APIs intercepted at the network layer — asserting auth headers, model, and body shape with zero API spend.

A UI regression suite against the live site feels like overkill until the first time it catches a stripped stylesheet before a user does. Mine paid for itself in week one.

Where It's At

LaunchPad is live at launch.tapdot.org — there's a sample launch you can explore without signing up if you want to see what one brief turns into. Everything is free for your first launch, including the cloud engines with your own key.

I'd genuinely like feedback on the channel prompts — each of the 42 has a hand-tuned "native voice" instruction, and the difference between a Show HN that survives and one that sinks lives in those words. If you launch somewhere I don't cover, tell me and it'll probably exist by next week: most of this product was built from user requests within hours of hearing them.

Happy to answer anything about the Prompt API, the BYO-key architecture, or the regression setup in the comments.

Introducing CommentIQ: On-Device AI for YouTube Comment Analysis

Mohan — Sun, 05 Jul 2026 09:00:27 +0000

CommentIQ is a Chrome extension that reads the comments section of any YouTube video and runs sentiment analysis, topic clustering, and question extraction — entirely on your device using Gemini Nano. No API calls, no backend, nothing leaves the browser. This is a writeup of the parts that actually gave us trouble.

Getting comments without an API

YouTube killed public API access for comments years ago. That means the only way to read them is from the page itself.

YouTube is built on Polymer with custom elements — ytd-comment-renderer, ytd-comment-thread-renderer and friends. They're not plain HTML. The text you want sits inside a #content-text element nested several shadow-DOM layers deep in each renderer. Querying for it is straightforward once you know the selector; the hard part is when to query.

Comments don't exist in the DOM when the page loads. YouTube lazy-loads them as the user scrolls toward the bottom of the page. We initially tried waiting for a fixed delay after navigation — fragile, obviously — before switching to a MutationObserver watching ytd-comments:

const observer = new MutationObserver(() => {
  const threads = document.querySelectorAll('ytd-comment-thread-renderer');
  if (threads.length > 0) {
    observer.disconnect();
    extractAndAnalyze(threads);
  }
});
observer.observe(document.body, { childList: true, subtree: true });

This worked until we hit YouTube's intersection-observer-based lazy render: threads exist in the DOM but their inner content isn't populated until they scroll into view. We ended up triggering a programmatic scroll to force the first batch to render, then immediately scrolling back. Hacky, but reliable.

YouTube is a SPA and it will surprise you

The bigger navigation problem: YouTube never does a full page load between videos. It's a single-page app using the History API. Your content script loads once per tab and keeps running as the user clicks from video to video.

chrome.webNavigation.onHistoryStateUpdated fires for each video navigation, but it fires before the new page's DOM is ready. We had to debounce and re-run the observer setup on each navigation event, making sure to cancel any in-flight analysis from the previous video first.

We also ran into the extension popup losing its connection to the content script mid-session. The pattern that worked: keep a port open between popup and content script, detect onDisconnect, and show a "reload the page" nudge rather than silently failing.

Feeding Gemini Nano without hitting the context limit

Chrome's built-in Prompt API (via window.ai.languageModel) has a context window. A popular video can have thousands of comments; sending all of them at once overflows it immediately.

We first check token capacity before each request:

const session = await window.ai.languageModel.create();
const available = session.tokensLeft;

Then we batch comments into chunks that each fit comfortably under the limit, run analysis on each chunk, and merge results. For sentiment this means averaging scores across chunks. For topic clustering we run a second summarisation pass over the chunk outputs rather than the raw comments.

The model also needs to be downloaded before first use. window.ai.languageModel.capabilities() returns { available: 'readily' | 'after-download' | 'no' }. When it's after-download we show a progress indicator and poll until it flips to readily. When it's no — typically because the device doesn't meet the hardware requirements — we surface a clear message rather than a silent failure.

Structuring the output

Raw Gemini Nano output isn't JSON. We prompt for structured output explicitly and then parse it, with a fallback for when the model goes off-script:

const prompt = `
Analyze these YouTube comments and return ONLY valid JSON with this shape:
{ "sentiment": { "positive": 0-100, "neutral": 0-100, "negative": 0-100 },
  "topics": ["string", ...],
  "questions": ["string", ...],
  "ideas": ["string", ...] }

Comments:
${batch}
`;
try {
  result = JSON.parse(await session.prompt(prompt));
} catch {
  result = fallbackParse(rawOutput);
}

The fallback uses regex to pull numbers and lists out of whatever text the model returned. It covers about 95% of the cases where strict JSON parsing fails.

Shipping without a backend

Like Margin, we wanted zero server infrastructure. Everything is stored in chrome.storage.local — analysis results are cached per video ID so re-opening the extension on the same video is instant.

The only outbound request CommentIQ ever makes is to Lemon Squeezy's public License API for key validation on the Pro tier. No secret is embedded in the extension; the API is designed to be called client-side. The license check runs once at activation and the result is cached locally — subsequent launches don't hit the network at all.

For the Chrome Web Store review we had to document this data flow explicitly. The reviewers flagged the activeTab and scripting permissions as potentially broad; the response was a clear explanation in the privacy policy that we only read from ytd-comment-renderer elements on youtube.com/* and never transmit that data.

What we'd do differently

The multi-pass chunking adds latency that's noticeable on videos with dense comment sections. A streaming UI — showing results as each chunk completes rather than waiting for the full merge — would hide this better. It's on the list.

The other thing: we underestimated how much YouTube's DOM changes between A/B test variants. The comment container selector broke twice during development because YouTube was testing different layouts. A more defensive selector strategy with fallbacks would save debugging time.

CommentIQ is live on the Chrome Web Store — free to install, no account required. Questions or feedback welcome in the comments.

Building tapdot tools: 90+ single-purpose utilities, zero backends, zero accounts

Mohan — Sat, 04 Jul 2026 18:40:21 +0000

I got tired of counting words for a blog draft on a site that wanted to email me a "productivity report" afterward. Then I needed to format some JSON and landed on a tool wrapped in ad networks with a cookie banner that took longer to dismiss than the formatting took to run. That's the origin story: every small utility I needed lived on a site that wanted something back — an email, a tracking pixel, an account "to save my history."

So I built tapdot tools — 92 tools now, one job each, no backend, no build step, no accounts, nothing you type ever sent anywhere unless the page says otherwise in plain English. This is the build log.

The pain point, specifically

A JSON formatter is maybe 40 lines of JS — building one isn't hard. The problem is the business model around free web utilities: it's almost always ads or data, because a one-off tool has no other way to pay for itself. You end up on a fragmented web where every tool lives on a different domain with a different privacy policy, half of which you didn't read.

The fix isn't a better tool. It's removing the reason to ever ask the question. If nothing leaves the browser, there's no policy to worry about.

Static, browser-only, no exceptions without a receipt

Every tool is plain HTML/CSS/JS in its own folder — no React, no bundler, no build step. That's not a performance flex, it's a trust mechanism: you can view-source any tool and see exactly what runs, because what runs is the source.

The rule I hold hardest: any tool that talks to the network has to disclose it, specifically, in the privacy policy. Right now that's two exceptions out of 92 tools — an optional URL-lookup proxy for one citation tool, and a currency exchange-rate fetch (rates only, never your amounts). Everything else is closed off from the network entirely by construction, not by promise. I did prototype a dictation tool using the browser's speech recognition API, but killed it before shipping — more on why below.

Making 92 static pages feel like one app, without a router

The hard part of "no backend, no framework" is that plain multi-page sites feel like the '90s — full reload, white flash, lost scroll position. Two browser features did the whole job:

@view-transition {
  navigation: auto;
}

That animates the swap between pages natively — no client-side router, no virtual DOM. Pair it with Speculation Rules so hovering a link prerenders the destination in the background before you even click:

const specScript = document.createElement('script');
specScript.type = 'speculationrules';
specScript.textContent = JSON.stringify({
  prerender: [{ where: { href_matches: '/*' }, eagerness: 'moderate' }]
});
document.head.appendChild(specScript);

By the time your cursor lands on a link, the next page is often already rendered. It feels instant — two browser primitives, not a framework.

The CSS bug that kept coming back

This one bit me four separate times before it clicked. Cards would overflow on mobile even though every child inside was already told to shrink. Turns out CSS Grid and Flexbox children have an implicit min-size: auto — they won't shrink below their content's intrinsic width unless you override it, and that has to happen at every level of nesting, not just the outer container:

.ts-select { min-width: 0; max-width: 100%; }
.ts-workbench > * { min-width: 0; }
.dev-row { min-width: 0; }

Fix one nested grid, ship a new tool with a nested grid three weeks later, hit the exact same overflow again. It's now a standing rule in the project: any new nested grid/flex layout gets min-width: 0 at every level, on sight, because I got tired of rediscovering the same CSS spec behavior.

Real crypto, not remembered crypto

When I added a password-hashing tool, the tempting shortcut was writing bcrypt from memory. I didn't. Hand-transcribing Blowfish S-boxes or an Argon2 mixing function from memory, in a tool whose whole job is producing correct hashes, is exactly where "roughly remember" becomes a silent bug nobody catches until it matters. Instead I vendored hash-wasm's actual WASM builds of the reference C implementations — self-contained, embedded as base64, no runtime fetch — and wrote round-trip tests (hash → verify → reject-wrong-password) before trusting it. Local-only and "don't write your own crypto" pulled in the same direction here.

Gating on-device AI without lying about it

A few tools use Chrome's built-in on-device model APIs — genuinely on-device, no server round-trip. But "on-device AI" fails in more states than "works" or "doesn't": model not downloaded, unsupported GPU, wrong browser. I wanted to avoid a dead button with a spinner.

async function checkSupport() {
  if (!('Writer' in self)) { gate('no', 'Not available in this browser'); return; }
  const avail = await Writer.availability();
  if (avail === 'unavailable') { gate('no', "This device can't run the model"); return; }
  gate('ok', avail === 'available' ? 'Ready' : 'Will download on first use');
}

The rule that came out of this: only call availability() passively on load. Never spin up a real session just to check if you can — that's what actually triggers the download, so it has to happen on a genuine click, not a background probe.

The tool I killed on principle

I built a dictation tool using the browser's built-in speech recognition API and got it fully working — live transcript, punctuation voice commands, the works. Then I pulled it before shipping. Chrome's SpeechRecognition sends your microphone audio to Google's speech-to-text servers to produce the transcript — there's no way around that with today's Web Speech API. I tried making the exception loud instead of quiet: a callout above the tool, a dedicated privacy-policy section, footer text spelling out exactly what happens. It still didn't sit right. If "nothing leaves your device" has an asterisk, it's not really the promise anymore, disclosure or not — so the tool didn't ship. Better to have 92 tools that all mean the same thing than 93 where one needs a footnote.

The full list — all 92 tools, by collection

Everything below runs at tools.tapdot.org — click any name to open it directly.

📚 Study (4)

CiteMaker — APA, MLA, Chicago, Harvard citations
FlashForge — Flashcards with spaced repetition
GradeCalc — GPA, weighted grade, final exam calculator
BiasCheck — Media bias & loaded language analyser

✍️ Write (4)

ReadScore — Flesch-Kincaid readability analysis
WordCount Pro — Word count, keyword density, live
LoremCraft — Placeholder text in 10 styles
ThreadCraft — Split long text into a tweet thread

🛠️ Dev (27)

JSONLab — Format, validate, minify, diff JSON
JSONConvert — JSON to YAML, CSV, XML, TOML
JWTStudio — Decode & inspect JWT tokens
YAMLCheck — YAML validator & formatter
CSVExplore — Sortable, filterable CSV viewer
MarkdownLive — Markdown editor with live preview
HTMLPreview — Sandboxed HTML renderer
SQLFormat — SQL formatter & beautifier
ColourContrast — WCAG AA/AAA contrast checker
UUIDGen — UUID v4/v7, ULID, nanoid generator
TimezoneNow — World clock & meeting overlap finder
TZConvert — Convert a date & time across timezones
RegexLab — Regex tester with match highlighting
CronLab — Cron expression workbench
Base64Tool — Encode and decode Base64 live — standard or URL-safe
DiffCheck — Line-by-line text comparison, fully local
WSTester — Connect and test WebSocket servers from your browser
CodePlay — HTML/CSS/JS playground with live preview and console
BigOCheck — Estimate time complexity from code structure
WorldClock — Airport-style analog world clocks, TV fullscreen
TimestampConvert — Unix timestamp <-> date, live, across timezones
JSONCSV — Convert JSON arrays to CSV and back
HashGen — SHA-1/256/384/512 hashes for text or files
KeyGen — RSA/ECDSA keypair generator, exported as PEM
PassHash — Hash and verify passwords with real bcrypt/Argon2id (WASM)
SVGClean — Strip editor cruft, comments, and excess precision from SVG markup
SQLObfuscate — Anonymize table/column names and literals in a SQL query

📣 Marketing (8)

UTMBuilder — Build UTM tracking links — history saved locally
HeadlineScore — Score headlines for clarity, emotion, and SEO
EmailSubjectTester — Spam triggers, mobile preview, sentiment
AdCopyWriter — Google, Meta and LinkedIn ad copy from a brief
SocialCalendar — Plan your content calendar — saved locally
PersonaBuilder — AI-assisted customer personas, saved locally
CompetitorMatrix — Feature comparison matrix — export CSV or Markdown
ROICalculator — ROI, ROAS, CPA, CLV and payback period

💰 Finance (11)

CompoundCalc — Compound interest with monthly contributions
BudgetPlanner — 50/30/20 budget split with a donut chart
MortgageCalc — EMI, amortisation schedule, overpayment savings
InvestmentTracker — Portfolio holdings, returns, and allocation
TaxEstimate — Income tax for India, US or UK
CurrencyConvert — 170+ currencies — rates cached daily
EquityCalc — Cap table dilution across funding rounds
NetWorthTracker — Assets minus liabilities, tracked monthly
LoanCalc — EMI, amortisation, and part-payment impact for any loan
RetireCalc — Retirement corpus needed vs on track — and the gap
InflationCalc — What inflation does to your money over time

⚖️ Legal (6)

ContractRead — Plain-English contract summary — on-device AI
NDAGenerator — Mutual or one-way NDA from a template
PrivacyPolicyGen — GDPR/CCPA-aware privacy policy generator
TermsBuilder — Terms of Service from a template
CopyrightChecker — Estimate public-domain status by jurisdiction
LegalGlossary — 130+ legal terms explained in plain English

🧑‍💼 HR (6)

SalaryBand — Pay grades, compa-ratio, range visualisation
JobDescriptionWriter — Inclusive job descriptions via on-device AI
InterviewKit — Role-specific questions and a scoring rubric
OfferLetterBuilder — Professional offer letter from a template
OnboardingChecklist — Day 1 / Week 1 / Month 1 checklist, saved locally
LeaveCalculator — Accrual, balance, and carry-forward

🩺 Health (6)

BMICalc — BMI, BMR, TDEE and healthy weight range
MedicationLog — Medications, doses and adherence rate
SymptomDiary — Log symptoms and severity on a calendar
CycleTracker — Predict next period and fertile window
WaterIntake — One-tap hydration logging and streaks
SleepLog — Sleep duration, quality and AI pattern analysis

🎨 Design (9)

SketchPad — Local whiteboard — pen, shapes, arrows, text, PNG export
PhotoTune — Local photo editor — filters, rotate, resize, export
PaletteForge — Colour palettes with CSS/Tailwind export and contrast ratios
TypographyScale — A harmonious 9-step type scale from base size and ratio
IconExplorer — A curated outline icon set — copy as SVG, JSX, or Vue
ShadowStudio — Layered CSS box shadows visually, with presets
SpacingCalc — Linear or multiplicative spacing scale, with export
GradientMaker — Linear, radial, and conic CSS gradients visually
ImageCompress — Resize and recompress images locally — JPEG/WebP/PNG

✅ Productivity (7)

UnitConvert — Every common unit converted live, with full tables
FocusTimer — Pomodoro-style focus sessions with notifications
QuickNote — A fast, private notepad that autosaves as you type
DecisionMatrix — Weigh criteria, rate options, see which wins
MeetingTimer — See the real cost of your meeting, live
HabitTracker — Daily habits with streaks and a heatmap
ReadingList — Save articles and books, track status and notes

🤖 Chrome AI (4)

AISummarize — Summarize long text on-device — TL;DR, key points, headline
AITranslate — Translate between languages on-device with auto-detection
AIWrite — Draft an email, post, or message from bullet points — on-device
AIRewrite — Change the tone or length of text — on-device

What's next

The repo's public: github.com/mohan-venkatakrishnan/tapdot-tools.

I'd genuinely like feedback on where I drew the line with the dictation tool — was killing it the right call, or is a loud, honest disclosure enough to justify keeping a tool that isn't fully local? Curious how others building free-but-honest tools have drawn that line.

And if there's some small utility you keep reaching for that always comes bundled with ads, logins, or a privacy policy you'd rather not read — tell me in the comments. If it can be done fully client-side, I'll build it.

Building Margin: A Privacy-First News Reader Inside Chrome's Side Panel

Mohan — Sun, 21 Jun 2026 18:42:21 +0000

I built a Chrome extension called Margin — a news reader that lives in
the browser's side panel and shows one bite-sized story at a time, instead of
an infinite-scroll feed. This is a build log: the decisions, the constraints
that pushed back, and a couple of things I had to solve in slightly unusual
ways.

Why the side panel

Chrome shipped chrome.sidePanel in MV3 a while back and most uses I saw were
utility tools — note-taking, translation helpers. Nobody was using it for
content consumption. News felt like a good fit: a side panel that stays open
next to whatever you're working on, where you tap through headlines in a
couple of minutes without leaving the page.

The reading model is intentionally narrow: one card, one headline, one short
summary, tap to read the full article at the source. No infinite scroll, no
algorithmic feed. If you've used InShorts, the shape will be familiar.

The stack

Preact + Vite + @crxjs/vite-plugin. Preact because the side panel is a small
UI surface and I didn't want React's weight for what's essentially a card
stack and a settings screen. @crxjs/vite-plugin handles the MV3-specific
build wiring (manifest generation, service worker loader, HMR for the
extension context) that would otherwise be a lot of manual plumbing.

The constraint that shaped onboarding

chrome.sidePanel.open() requires a user gesture. You cannot call it from
a background service worker on install — Chrome will throw. That one
constraint shaped the whole first-run experience.

My first instinct was "just auto-open the panel on install so people see it
immediately." Doesn't work. The fix ended up being two-pronged:

On chrome.runtime.onInstalled with reason === 'install', open a real browser tab with a short walkthrough (find the icon → pin it → open the panel). The button on that page calls sidePanel.open() — valid, because the click is the gesture.
The first time the panel itself is opened, show an in-panel welcome screen before onboarding, nudging the user to pin the toolbar icon for one-click access later.

chrome.runtime.onInstalled.addListener((details) => {
  if (details.reason === 'install') {
    chrome.tabs
      .create({ url: chrome.runtime.getURL('src/welcome/index.html') })
      .catch(() => {})
  }
})

Small platform detail, but it's the kind of thing that's invisible until you
hit it, and then it reshapes a whole feature.

Getting "swipe" right

The card stack supports scroll-to-advance, and the obvious naive approach —
just listen to wheel/scroll deltas — over-advances. A fast trackpad swipe can
fire a dozen scroll events, which without debouncing skips two or three cards
at once.

I went back and forth on this. My first fix added "re-acceleration"
detection — trying to distinguish a continued gesture from a new one based on
velocity changes. It technically worked but was fragile and hard to reason
about. I ended up ripping it out in favor of something much simpler: track an
idle gap between scroll events, and treat direction reversal as a new
gesture. One card per gesture, full stop. Less clever, far more predictable —
and it's the version that's actually shipped.

Lesson: when a heuristic needs increasingly special-cased logic to handle
edge cases, that's usually a sign the simpler version was right and the bug
was somewhere else.

Privacy, by removing things rather than adding them

Margin has no backend. There was never a backend to remove, which made the
privacy story straightforward instead of aspirational:

RSS feeds and article pages are fetched directly from publishers, from the user's machine.
Optional AI summaries run on-device via Chrome's built-in Summarizer (Gemini Nano) — article text never leaves the browser.
Settings, cached cards, and reading stats live in chrome.storage.local. Nothing is transmitted anywhere unless the user explicitly buys the paid tier (more on that below).

The only design wrinkle: Chrome's on-device model has an eligibility/
provisioning step, and defaulting summaries to "always on" produced errors on
devices that didn't support it yet. Fix was a tri-state preference —
auto | on | off — where "auto" silently checks device support before
turning summaries on, instead of assuming.

Monetization without becoming a backend

For the optional Plus tier, I didn't want to stand up a server just to gate
features. I used Lemon Squeezy as merchant of record: checkout happens on
their hosted page, the user gets a license key by email, and the extension
activates/validates that key against Lemon Squeezy's public License API.

const res = await fetch('https://api.lemonsqueezy.com/v1/licenses/activate', {
  method: 'POST',
  headers: { Accept: 'application/json' },
  body: new URLSearchParams({ license_key: key, instance_name: 'margin-extension' }),
})

No secret key required client-side, no server to run, and Margin never
touches payment details. The whole "Plus" gate is just: is there a valid
license key in local storage?

Where it's at

It's live on the Chrome Web Store — free tier covers 3 topics and a couple of
themes, Plus unlocks the rest. I'd genuinely like feedback on the reading
flow in particular, since "one card at a time" is a more opinionated UX
choice than a typical feed and I want to know if it actually lands for people
who try it.

Margin - Chrome Web Store

Bite-sized news in your side panel.

chromewebstore.google.com

Happy to answer questions about the side panel API, MV3 service worker
quirks, or the licensing setup — ask away.

I built a Chrome extension that shows which tab is eating your RAM (and frees it in one click)

Mohan — Thu, 18 Jun 2026 06:34:53 +0000

The problem I kept running into

I'm a chronic tab hoarder. At any given time I've got 40–80 tabs open across two windows. Chrome's built-in Memory Saver is aggressive in the wrong ways — it hibernates tabs I'm actively referencing. And the built-in task manager is a two-step detour that still doesn't tell me which tabs I should actually close.

So I built Tab Memory Manager.

What it does

Per-tab memory estimates — A live MB count next to every open tab. Sorted by memory usage by default. There's a live total on the toolbar icon so you always know what Chrome is consuming right now.

Smart suggestions — The extension flags your biggest, stalest tabs: ones that are idle the longest and consuming the most. It never suggests your active tab, pinned tabs, tabs playing audio, or domains you've whitelisted.

Hibernate, don't close — This was the core design decision. Hibernating frees the memory but keeps the tab alive in your strip — it reloads when you click it. Much safer than closing, especially mid-research.

Bulk cleanup — Select multiple tabs or hit Apply on the suggestions panel. See the total memory you'll reclaim before you commit.

Undo list — Closed something by mistake? There's a "Recently cleaned" panel. One click to restore.

Tab grouping — Groups all your open tabs by domain into color-coded Chrome tab groups, instantly.

The interesting technical bit: memory estimates

Chrome's stable extension API doesn't expose exact per-tab memory. The chrome.processes API that does exists only on Dev and Canary builds — not the Chrome that 99% of people use.

So Tab Memory Manager uses calibrated estimates based on tab state, domain patterns, and known Chrome process overhead. These are clearly labeled "est." in the UI. If you're on Dev or Canary, you can switch on real per-tab memory in settings.

The warning Chrome shows about "processes requires dev channel" is a Chrome-generated note about that optional API — the extension works completely normally without it. It's not a bug.

The privacy angle

No accounts. No servers. No analytics. No network requests at all (except to load the extension itself). Your tab data never leaves your browser.

This was a hard constraint from the start — I didn't want to build a tool that phones home with your browsing habits in exchange for memory stats.

What I learned building it

Chrome's memory API situation is messier than I expected. There's no clean "give me memory per tab" call on stable Chrome. The estimates approach took real calibration work.
Hibernation UX is tricky. Users expect the tab to stay exactly where it was. Making that feel seamless (instant reload on click, right scroll position, no flash) took more edge-case handling than the core feature.
"No frameworks" was the right call here. The extension opens in under 100 ms. That matters when you're in the middle of a task and just want to quickly free some memory.
Dark mode should be automatic, not optional. Used CSS variables throughout so dark/light adapts to the user's system preference without any user-facing toggle.

Try it

It's free on the Chrome Web Store. I'd genuinely love feedback — especially from people who've tried other tab suspenders and found them lacking.

Link:

Tab Memory Manager - Chrome Web Store

See estimated memory per tab, hibernate or close idle tabs in one click, and group tabs by domain. Everything stays on your device.

chromewebstore.google.com

What would make this more useful for your workflow?

Building Floatdeck - Chrome extension with 30+ tools and no backend

Mohan — Tue, 16 Jun 2026 18:47:12 +0000

Weekend project to scratch an itch: I had five separate extensions — screenshot, dark mode, reading mode, QR, link cleaner — each eating a toolbar slot, a couple clearly monetizing my data. So I rolled them into one draggable floating button that fans open into a radial menu of ~30 actions.
A few decisions worth noting:

No backend, no analytics, zero network calls. Everything runs locally. That constraint makes the privacy story trivially honest and removes all the server/auth/policy overhead. If a feature needed a server, it didn't make the cut. Bundle's ~50KB.
Vanilla JS, MV3, Shadow DOM. Since it injects into every page, I wanted it tiny — no framework. Shadow DOM to isolate the button from host-page CSS, which killed a whole class of style-collision bugs.
The radial menu — not sure it was right. Looks great, feels nice for 5–6 items, but past that I doubt it beats a plain list for scanability (Fitts's law hates small icons on an arc). Kept it for the aesthetic. Curious if anyone's actually measured this.

It's on the Chrome Web Store if you want to poke at it (disclosure: I'm the dev, free, no account, no telemetry). Mostly posting for the discussion though — how would you have handled the menu layout?

FloatDeck - Floating Button Menu & Quick Actions - Chrome Web Store

A draggable floating button that opens a radial menu of quick actions — screenshots, reading & dark mode, QR, copy, and more.

chromewebstore.google.com