DEV Community: tinycoder-studio

I Built a Gumroad Telegram Sale Alert in 5 n8n Nodes. Zapier Charges $20/mo and Still Delays It 15 Minutes

tinycoder-studio — Tue, 22 Sep 2026 10:04:59 +0000

Your product sells at 2:47am. You find out at 9:15am, when you check email and the Gumroad notification is sitting three promotions down in your inbox.

That's the problem nobody sells a fix for, because the fix is boring: know the instant a sale happens. Not when you check the dashboard. Not when the weekly payout email lands. When it happens.

Someone put it better than I can. One comment on my last post: "silent sales you didn't even know about." That's the pain. Gumroad already emails you, but email waits for you, and you're not a notification, you're a person with a life. Sales fire at all hours, and you're not watching.

So I built the dumbest thing that solves it: a 5-node n8n workflow that pushes a Telegram alert to my phone the moment Gumroad pings. No polling. No monthly fee. Nothing else to babysit. And yeah, Zapier charges about $20/mo for a version that's still 15 minutes late on its free tier.

What I built: five nodes, one line

This is the workflow that survived my 7-setup n8n teardown, the one I called "the rare workflow that's exactly as simple as it looks." It's a straight line: webhook in, Telegram out, nothing in between that can rot.

Five nodes, exact names, nothing invented:

Webhook: Gumroad Sale (n8n-nodes-base.webhook) — Gumroad POSTs to /webhook/gumroad-sale on every new sale. This is the trigger. No cron, no scheduler, no compute while idle.
IF: Is a Sale? (n8n-nodes-base.if) — passes only payloads that carry a sale_id. This one node exists to kill Gumroad's test ping, which it fires the moment you save the webhook URL. Without it, you'd alert yourself on an imaginary sale.
Format Telegram Message (n8n-nodes-base.function) — builds the alert text. Paid sales get a 💰 header and a price line; free downloads get a 🎁 header. Product name, buyer email, timestamp.
Telegram: Send Alert (n8n-nodes-base.httpRequest) — a plain POST to the Telegram Bot API sendMessage endpoint. Token and chat ID come from env vars, never hardcoded.
Respond (n8n-nodes-base.respondToWebhook) — returns HTTP 200 so Gumroad knows the ping landed and stops retrying.

That's the whole thing. Five nodes, one straight line, no community nodes, no n8n credentials to configure. The bot token lives in the request URL, pulled from $env.TELEGRAM_BOT_TOKEN, which works on both n8n Cloud and self-hosted.

The Zapier math: $20/mo and still 15 minutes late

Here's the comparison that made me build this instead of using the obvious tool.

Zapier's free tier polls your Gumroad account every 15 minutes. That means a sale at 2:47am is discovered somewhere between 2:47 and 3:02, so worst case you're a quarter hour late, on average 7.5 minutes. And the free tier ships with a 100 tasks/month ceiling. Cross it mid-month and your automation just stops running until the calendar flips. On a product that sells, that's not a tool, that's a lottery.

Want it faster? Zapier's paid tier runs about $20/mo (Professional, billed annually). What you buy is a shorter poll interval, not no interval. It's still polling. Every sale still waits for the next poll cycle to notice it. You're paying monthly, forever, for the privilege of being less late.

The n8n workflow doesn't poll at all by design. Gumroad's webhook is a push: the moment a sale lands, Gumroad fires a POST at my URL. No interval to miss, no recurring subscription. Self-hosted on your own box, the runtime cost is $0, and the workflow fires only when something actually happens.

	Zapier Free	Zapier Professional	This n8n workflow
How it finds sales	Polls every 15 min	Polls (shorter interval)	Webhook push, no polling
Worst-case delay	~15 min	Interval-bound, still >0	Zero by design*
Task ceiling	100/month	Higher, still capped	None
Cost	$0	~$20/mo, forever	$0 (self-hosted)

*Zero by design: the webhook fires when Gumroad pings. I'm not going to sell you latency numbers this thing hasn't earned in production; the architecture just has no poll cycle in it.

Inside the workflow: the JSON nobody screenshots

Everyone posts the canvas screenshot. Nobody shows the code. Here's the actual node config from the import file, so you can judge it like a developer instead of like a customer.

The filter lives in one condition on the IF node:

`json
{
  "name": "IF: Is a Sale?",
  "type": "n8n-nodes-base.if",
  "parameters": {
    "conditions": {
      "boolean": [
        { "value1": "={{ $json.sale_id != null }}", "operation": "true" }
      ]
    }
  }
}

No sale_id, no alert. That's the entire spam filter.

The formatter is where the message takes shape, and where the Gumroad payload quirks get handled:

`js
const sale = $json;
const product = sale.product_name || 'Unknown product';
const email = sale.email || 'no email captured';
const when = sale.timestamp ? new Date(sale.timestamp * 1000).toISOString() : new Date().toISOString();
const isPaid = (sale.price || 0) > 0;
const currency = sale.currency || 'USD';

const lines = [
isPaid ? '💰 PAID SALE' : '🎁 FREE DOWNLOAD',
'',
Product: ${product},
Buyer: ${email},
Time: ${when}
];
if (isPaid) lines.splice(3, 0, Price: ${currency} ${(sale.price / 100).toFixed(2)});

return [{ json: { message: lines.join('\n'), is_paid: isPaid } }];
`

Gumroad sends price in cents, which is why the code divides by 100. timestamp arrives in unix seconds, hence the * 1000. Both are payload quirks that would've had me staring at a wall for an hour if I'd hit them blind, so they're handled in the node instead of in your head.

The send is a one-liner HTTP request reading two env vars, so your token never sits in the workflow JSON:

json { "name": "Telegram: Send Alert", "type": "n8n-nodes-base.httpRequest", "parameters": { "url": "= {{ 'https://api.telegram.org/bot' + $env.TELEGRAM_BOT_TOKEN + '/sendMessage' }}", "method": "POST", "jsonParameters": true, "bodyParametersJson": "={{ { chat_id: $env.TELEGRAM_CHAT_ID, text: $json.message, parse_mode: 'HTML' } }}" } }

One more thing you get for free: free downloads alert too. isPaid branches the header (💰 vs 🎁), and the price line only shows up on paid sales. Tracking free downloads in real time tells you when a launch post is actually landing, which is worth more than the paid alerts in the early days.

What you'll get on your phone looks like this, straight from the formatter above:

Honest limitations (read this before importing)

I'm not going to bury the caveats, because the caveats are the part that's actually true.

Structurally validated, not production-tested. This workflow parses clean, the wiring is verified node-to-node, and it's version-pinned to n8n 1.x. It has not been run against a live n8n instance or a real Gumroad sale in my environment. That's the entire honesty envelope: structurally valid and import-ready, not "battle-tested at scale." Test it before you rely on it, trigger Gumroad's test ping, or buy your own product for $0, and confirm the message lands. If that caveat bothers you, good. It should.

Self-hosted means public. Gumroad has to reach your webhook. If your n8n runs on localhost, Gumroad can't find it, and no amount of workflow cleverness fixes that. You need either n8n Cloud (the free tier works for a single workflow like this) or a self-hosted instance with a public URL.

The workflow ships inactive. The import file has active: false, because nobody should ship a workflow that starts firing at strangers the second it's imported. You flip the toggle, copy the /webhook/gumroad-sale URL, and paste it into Gumroad → Settings → Advanced → Webhooks.

It's fire-and-forget. No retry queue, no database, no dedupe beyond the sale_id filter. If Telegram is down, the alert is gone. For a "I want to know a sale happened" push, that's the right trade. For a financial system, it isn't, but then again, neither is Zapier.

Take it, it's free

This workflow is a free download: import-ready JSON, MIT licensed, no catch beyond an email address so I can send you the setup doc (5 minutes, BotFather → bot token, env vars, import, activate, paste webhook URL).

Download the Gumroad Sale → Telegram Alert workflow →

I'm also building a full pack around the workflows that survived the teardown, tested-by-inspection n8n workflows plus AI agent prompt skills, $29 on Gumroad. The free workflow is the on-ramp: if a 5-node sale alert is your kind of boring, the pack is the rest of it.

Your product is going to sell at 2:47am someday. The only question is whether you find out at 2:47am, or at brunch.

I Tested 7 n8n Agent Setups So You Don't Have To. Here's What Actually Survived

tinycoder-studio — Sun, 20 Sep 2026 14:10:44 +0000

I Tested 7 n8n Agent Setups So You Don't Have To. Here's What Actually Survived

n8n is where "AI agent" marketing goes to die.

Every week there's another post. Beautiful canvas screenshot, nine nodes, "agentic workflows that run your business while you sleep." The comments fill up with the same question — does it actually work? — and nobody answers.

So I did the annoying thing. Built seven n8n agent setups, ran each through a structured validation pass, documented what it did, kept the ones that survived. No revenue screenshots. No "make $X/month" nonsense. Just what holds up and what doesn't.

What "tested" means here (read this before you judge)

Most "tested" claims on the internet mean "I ran it twice and took a screenshot." I want to be more precise than that.

Here's exactly what I did with each setup:

Validated the JSON structure — it parses clean, no malformed nodes
Verified the node wiring — every connection points at a real node, no dangling references
Version-pinned each workflow to n8n 1.x so it doesn't silently break on the next release
Reviewed the design against the failure modes that kill agent workflows

What I did not do: run any of these in a live n8n instance, execute them against real services, or load-test them. No 10,000-requests-a-day claim, no "battle-tested at scale." Structurally validated and design-reviewed, not runtime-tested. If that's not enough for you, good. You should read everything on the internet the same way.

The 7 setups

1. Gumroad sale → Telegram alert — SURVIVED

A webhook trigger on Gumroad's sale event, a filter, a formatter, a Telegram message, and a response node. That's it. Five nodes. When a sale lands I get a push notification with product name, price, and buyer email.

Why it survived: it's the rare workflow that's exactly as simple as it looks. Trigger-driven (fires only when something happens, burns zero compute sitting idle), single-purpose, deterministic output. Every other workflow on this list gets measured against it. Details below, and it's yours for free.

2. Webhook → route task to specialist agent — SURVIVED (with a caveat)

The multi-agent router: one webhook in, a keyword/pattern router, task dispatched to the right specialist. Works, as long as your routing rules are a fixed schema and not vibes. The moment I tried "let the LLM decide the route," outputs got clever in the bad way.

The caveat: a router is only as good as the contract between agents. Define the input schema first, then the routes. No schema, no survival.

3. Webhook → security scan → Slack alert — SURVIVED (as a linter, not a scanner)

Feeding code through a vulnerability-pattern scanner and alerting on hits. As a quick trigger-driven check on pasted snippets, genuinely useful. As a security product, it isn't. It's a regex linter, and pattern lists rot fast. Treat it as a first pass that catches the obvious stuff (hardcoded secrets, eval, SQLi patterns) and you're fine.

4. Webhook → humanize text → metrics — SURVIVED (as a formatting pass)

The honest take: "humanization" via phrase replacement is a formatting pass, not magic. It kills the most obvious AI tells ("In today's digital landscape", "it is important to note") and reports the before/after. It survived because it does one thing and reports what it did. It did not survive as a rewrite engine. LLM-generated rewrites drift, and you pay per call.

5. Webhook → analyze content → SEO report — SURVIVED (but it's commodity)

Sentiment, keyword extraction, reading time, a quick SEO readout. Useful, deterministic, survived the pass. But a dozen other tools do this. It's a nice-to-have in a pack, not a reason to buy one.

6. Pay-per-call x402 API server — BROKE

This one tried to be a product inside a workflow: crypto wallet, USDC payments, Cloudflare tunnel, payment verification, rate limits. The design review found a wall of surface area that murders the "5 minute setup" promise. Every dependency (wallet setup, facilitator verification, tunnel flakiness) is a new way to fail. The revenue table everyone quotes in these posts is fantasy without distribution. Nobody calls an API nobody knows exists.

Why it broke: it monetized before it validated. Get the workflow working for one human first. Bolt on payments later, if ever.

7. Scheduled "agent digest" — cron scrape → summarize → send — BROKE

The classic: every morning, scrape a few sources, summarize, send to Telegram. The design kills it: scheduled, non-deterministic, silent failure. Sources change their HTML structure, feeds go stale, and an AI summarizer will happily summarize garbage with total confidence. Nobody watches a cron job, so nothing fails loudly.

Why it broke: not trigger-driven, output not deterministic, failure wasn't loud.

What the survivors have in common

Seven setups, two patterns. The five survivors share three traits:

Trigger-driven, not scheduled. They fire when something happens (a webhook, a sale, a manual test). Nobody watches them, so nothing rots silently.
Single purpose, deterministic output. JSON in, formatted message out. The dumber the contract, the longer the workflow lives.
Failure is loud. Error paths are actual paths, not afterthoughts.

The two that broke tried to be products: payments, scheduling, open-ended generation. That's the line, and it's sharp.

The one worth stealing (free, no catch beyond an email)

Every digital creator needs this one first: knowing a sale happened in real time. Not a dashboard you check, a push notification that lands while it's still happening.

The workflow that survived the cleanest is the Gumroad Sale → Telegram Alert. Import-ready JSON, MIT licensed, free download. Five nodes:

Gumroad Webhook — Gumroad pings it on every new sale
Filter — only real sales, skip test events
Formatter — builds the alert message
Telegram — sends the alert to your chat
Respond — answers Gumroad so it stops retrying

The key node, so you can see it's not a screenshot of a dream:

{
  "name": "Telegram: Send Alert",
  "type": "n8n-nodes-base.httpRequest",
  "typeVersion": 2,
  "position": [850, 300],
  "parameters": {
    "url": "= {{ 'https://api.telegram.org/bot' + $env.TELEGRAM_BOT_TOKEN + '/sendMessage' }}",
    "method": "POST",
    "jsonParameters": true,
    "bodyParametersJson": "={{ { chat_id: $env.TELEGRAM_CHAT_ID, text: $json.message, parse_mode: 'HTML' } }}"
  }
}

Setup is about five minutes: import the JSON, set two environment variables (your Telegram bot token and chat id), plug in your Gumroad webhook URL (Gumroad settings → Ping → point it at the webhook node), done. Works on n8n cloud or self-hosted, nothing else to install.

One honest gotcha so you don't lose twenty minutes like I did: Gumroad sends test notifications when you first save the Ping URL. Trust the filter node. It's there specifically so you don't alert yourself on an imaginary sale.

Download the free workflow → (Free, email required — you'll get the setup doc plus updates when I add more workflows.)

The pattern, not the pack

If you take one thing from this: the workflows that survive are the boring ones. Trigger-driven, single-purpose, loud failures. Every "agent empire" post you see this week is selling you setup #6 or #7. The ones that broke.

I'm building a pack around the ones that survived, currently 5 skills + 4 n8n workflows, structured the same way each was validated here, expanding to 15–20 tested workflows. If that sounds like your kind of boring: the free workflow above is the on-ramp, and the full pack is here if you want the whole validation, not just the survivor.

I Built a Headless Browser Toolkit With Chrome DevTools Protocol

tinycoder-studio — Thu, 17 Sep 2026 13:47:28 +0000

I Built a Headless Browser Toolkit With Chrome DevTools Protocol — Here Is the Full Architecture

I needed to post to Twitter, Reddit, and dev.to from one codebase. Twitter's API has rate limits. Reddit bans bots. dev.to is fine. So I wrote 54 lines of JavaScript that automates the whole thing — no API keys, no OAuth, just a headless Chrome doing what you'd do manually.

It's the browser automation equivalent of raw SQL. You skip all the abstraction layers and go straight to what actually works.

The Problem

Every platform says "use our API." So you do. Then:

Twitter API tiers are restrictive and expensive for indie devs. Free tiers barely cover casual use.
Reddit moderation is aggressive toward automation — accounts that post programmatically without human review get flagged quickly.
Gumroad's API covers product management, but it's limited compared to what you can do through their web interface. For complex product setups with multiple files and variants, browser automation is sometimes faster.
Google kills APIs every 18 months.

Meanwhile, the actual browser sitting on your machine can do everything a logged-in user can do. That's the gap I went after.

Puppeteer is maintained by the Chrome team and works fine, but the CDP docs are scattered across Chrome DevTools protocol pages that haven't been updated since 2020. Selenium is ancient — WebDriver is a different paradigm entirely. Cypress is for testing, not automation.

I wanted something that did one thing well: give me the browser so I can control it programmatically. 54 lines later, I had it.

The Solution — cdpp.js

Here's the entire wrapper:

const { chromium } = require('playwright')
let browser, page

async function connect(url) {
  browser = await chromium.launch({ headless: true })
  page = await browser.newPage()
  if (url) await page.goto(url)
}

Five lines to launch a browser. Playwright handles Chromium, Firefox, and WebKit — I only use Chromium. No config needed. No playwright.config.js. No test runners.

async function goto(url) { await page.goto(url) }
async function pageText() { return await page.textContent('body') }

Navigation and content reading. pageText() pulls all visible text from the page — useful for scraping, link checking, or verifying content posted correctly.

async function clickByText(text) {
  await page.click(`text="${text}"`)
}

Instead of brittle CSS selectors or XPath queries, I click by what the user sees. clickByText("Tweet") finds the first visible element containing that text and clicks it. Playwright's auto-wait handles the timing — no setTimeout hacks.

async function fillInput(selector, value) {
  await page.fill(selector, value)
}

async function setFileInput(selector, filePath) {
  await page.setInputFiles(selector, filePath)
}

Form filling and file upload. fillInput clears the field first, then types. setFileInput handles the <input type="file"> element that's invisible to normal click automation.

async function screenshot(path) {
  await page.screenshot({ path, fullPage: true })
}

async function evalInTab(js) {
  return await page.evaluate(js)
}

Screenshots for debugging or documentation. evalInTab runs arbitrary JavaScript inside the page context — the same as opening DevTools console and typing code.

async function disconnect() {
  await browser.close()
}

Cleanup. Releases the Chromium process.

54 lines total. Just functions that call Playwright.

Real Example: Posting a Tweet

Here's how twitter-poster.js uses the toolkit:

const cdp = require('./cdpp')

async function postTweet(text) {
  await cdp.connect()
  await cdp.goto('https://x.com/compose/post')
  await cdp.fillInput('[data-testid="tweetTextarea_0"]', text)
  await cdp.clickByText('Tweet')
  await cdp.screenshot('./tweet-posted.png')
  await cdp.disconnect()
}

That's the core. Navigate to the compose screen, fill the text area, click Tweet, screenshot for confirmation.

No API key. No OAuth. No rate limits. It works because the browser is already logged in — the session cookies are in the Chrome profile. Same way you'd post a tweet manually.

The real version handles login state detection, waits for the compose modal to fully load, and retries if Twitter's React app hasn't rendered the textarea yet. But the core flow is exactly this.

The API tiers make automation painful. CDP sidesteps those limits — you post as fast as the page loads.

Real Example: Filling a Gumroad Form

Okay but real talk — Gumroad's API covers product management, but it's limited for complex setups. Their internal endpoints require CSRF tokens that rotate. So I automate the form directly.

await cdp.goto('https://app.gumroad.com/products/new')
await cdp.fillInput('#product_name', 'My New Product')
await cdp.fillInput('#product_description', 'Product description here')
await cdp.fillInput('#product_price', '29')
await cdp.setFileInput('input[type="file"]', './cover.png')
await cdp.clickByText('Publish')

This fills 15+ fields — name, description, price, permalink, cover image, content files. The file upload uses setFileInput which handles the hidden <input type="file"> that Gumroad uses.

The full script processes a product definition from a JSON file and fills every field automatically. Before this, creating a product on Gumroad took 20 minutes of manual clicking. Now it takes 30 seconds.

This is how CDP works in practice: you use the exact same interface the human uses, sidestepping missing or rate-limited APIs.

The Contrast: CDP vs REST API

Look, I know what you're thinking — isn't this just reinventing the wheel? Not really. Here's the tradeoff, concrete:

dev.to posting — REST API (129 lines):

const response = await fetch('https://dev.to/api/articles', {
  method: 'POST',
  headers: { 'api-key': API_KEY, 'Content-Type': 'application/json' },
  body: JSON.stringify({
    title: 'My Post',
    body_markdown: content,
    tags: ['webdev', 'javascript']
  })
})

Clean. Well-documented. Rate-limited to 30 articles/30 seconds, which nobody hits. The API handles markdown rendering, tag validation, canonical URLs — everything.

Twitter posting — CDP (200+ lines):

Navigate. Wait for React to render. Find the textarea by data-testid attribute. Type content character by character (because React synthetic events don't trigger on page.fill). Click Tweet. Handle the confirmation modal. Screenshot.

When to use which:

	CDP	REST API
Speed	Slow (full page load)	Fast (single HTTP call)
Reliability	Breaks when UI changes	Stable with versioning
Auth	Browser session (cookies)	API key / OAuth token
Rate limits	Browser speed only	Platform-defined
Capabilities	Anything a user can do	Only what the API exposes
Maintenance	UI changes = your code breaks	API changes = you update

My rule: If the platform has a good API, use it. dev.to, GitHub, Slack — all have clean REST APIs. Use them.

If the platform's API is rate-limited, expensive, or missing features — use CDP. Twitter, Reddit, Gumroad, LinkedIn. The browser doesn't care about your API tier.

When Should I Use CDP vs REST API?

Use CDP when:

The platform has no API or a severely limited one
You need to perform actions that the API doesn't expose
API rate limits are blocking your automation
You need to use a logged-in session (no API key available)
The platform actively discourages automation (Reddit, LinkedIn)

Use REST API when:

The platform has a well-documented, stable API
You need speed (CDP is 10-100x slower per request)
You're building something that needs to run at scale
The API covers everything you need

Use both when:

You want reliability for the core flow (API) but need to handle edge cases (CDP)
You're migrating from one approach to the other

The toolkit supports both patterns. devto-poster.js uses the REST API. twitter-poster.js uses CDP. Same codebase, same patterns, different transport layer.

Why Not Just Use Puppeteer?

Puppeteer is fine. It works. But:

Playwright has better auto-wait. Puppeteer requires manual waitForSelector calls. Playwright waits for elements to be actionable before clicking. Fewer race conditions, less debugging.
Playwright supports multiple browsers natively. If you ever need to test in Firefox or WebKit, you're one line away. Puppeteer is Chromium-only.
Playwright's text= selector is magic. page.click('text=Submit') finds visible text. Puppeteer requires you to write your own XPath or use page.evaluate to find elements by content.
Playwright has faster feature velocity and broader browser support. Puppeteer remains maintained by the Chrome team with a CDP-first focus, but Playwright's API is more developer-friendly for automation tasks.

If you already have a Puppeteer codebase, don't rewrite it. But for new projects, Playwright is the better default.

The Architecture

cdpp.js (54 lines)
├── connect() → Playwright chromium.launch()
├── Navigation: goto(), pageText()
├── Interaction: clickByText(), fillInput(), setFileInput()
├── Observation: screenshot(), evalInTab(), listTargets()
└── Cleanup: disconnect()

Everything builds on top of this. twitter-poster.js imports cdpp. reddit-poster.js imports cdpp. verify-links.js imports cdpp. gumroad-upload.js imports cdpp.

One wrapper. Multiple tools. No shared state beyond the browser instance.

The listTargets() function is worth mentioning — it enumerates all open tabs and frames. Useful when you need to interact with popups or iframes without knowing their selector in advance.

The Reality Check

Browser automation violates the Terms of Service of most platforms. Account termination is a real risk. Use at your own risk.

Anti-bot systems (Cloudflare, DataDome, behavioral analysis) detect and block headless Chrome. Canvas fingerprinting, navigator.webdriver detection, and timing analysis are real. You'll hit walls on sites that invest in bot protection.

The 54 lines are the wrapper. Production scripts like twitter-poster.js are 200+ lines with retry logic, error handling, and session management. Don't expect to copy-paste the wrapper and have it work on every site.

CDP doesn't scale — one browser instance = one session. For scale, consider cloud browser services like Browserless or Browserbase.

Takeaway

Playwright + a thin CDP wrapper worked for me. Your mileage may vary.

If a platform's API is rate-limited, expensive, or missing features, browser automation is a viable fallback. The browser is the most universal interface we've built — every platform has a web version, and CDP lets you control it programmatically.

For new projects, start with the platform's API if one exists. When it doesn't — or when it's too restrictive — a small wrapper around Playwright gets the job done.

Found this useful? I'm building a PWA dev toolbox — check it out → TinyCoder Web Toolbox

How Independent Insurance Agencies Lose $50K+ Per Year in Missed Leads (And How to Fix It)

tinycoder-studio — Thu, 17 Sep 2026 03:33:16 +0000

Free Audit Link

How Independent Insurance Agencies Lose $50K+ Per Year in Missed Leads (And How to Fix It)

You run an independent agency. You have 5, 10, maybe 15 staff. Your book of business sits somewhere between $1M and $10M in annual premium. You're not a tech company — you're a people company that happens to sell insurance.

And somewhere between the quote request that lands on your website at 9:47 PM and the phone call your team makes at noon the next day, you're losing money you'll never see again.

This isn't a hypothetical. It's a line item on your P&L that doesn't show up as a line item — because you never had the revenue to begin with.

Let's talk about the real dollar cost of slow response, what the data actually says, and what you can do about it without hiring a tech team.

The Math: What a Missed Lead Actually Costs You

Start with the basics. The average independent insurance agency takes 47 hours or more to respond to a new lead, according to Onyx CRM. Not 47 minutes. Forty-seven hours.

Here's what that means in dollar terms.

Let's say your agency pays for internet leads — from a provider, from your website, from a referral partner. Each lead costs you somewhere between $25 and $75, depending on the source. A fair middle estimate for most independent agencies is $40 per lead.

If you're buying or generating 100 leads per month — again, a reasonable number for a mid-size independent — that's $4,000 per month in lead cost. $48,000 per year.

Now let's talk about what happens to those leads.

Only about 7% of agencies respond to leads within five minutes, according to Velocify. That's not a misprint. Seven percent. Which means 93% of your competitors are playing the same game you are — taking hours, sometimes days, to get back to a prospect who filled out a form or called in after hours.

Meanwhile, the research from InsideSales.com is unequivocal: agencies that contact leads within five minutes are 21 times more likely to qualify them compared to those who wait 30 minutes. And when MIT and InsideSales.com measured follow-up timing against actual conversation outcomes, agents who followed up within one hour were seven times more likely to have a meaningful conversation than those who waited even two hours.

Read that again. The window between one hour and two hours is where deals go to die.

Running the Numbers

If you generate 100 leads per month and your current speed-to-lead puts you in the 47-hour average, you're converting somewhere around 2-3% of those leads into policies. That's 2-3 new policies per month on a 100-lead spend.

If you moved your average response time under five minutes, and the 21x qualification multiplier holds even conservatively — say you only capture a fraction of that uplift — you're looking at 6-8 policies per month instead of 2-3. That's 3-5 additional policies per month.

At an average annual premium of $2,000 per policy, with an average commission of 12%, each additional policy is worth roughly $240 in first-year commission. Three to five extra policies per month is $720 to $1,200 in additional monthly revenue. Over a year, that's $8,640 to $14,400.

And that's just the first-year commission. What about renewals? What about the referral that comes from a client who had a great onboarding experience? What about the umbrella policy, the auto add-on, the commercial line they mention to their business partner?

Conservative estimate: a single well-handled lead is worth $500-$1,500 in lifetime revenue to your agency. When you're ignoring or under-following 95% of your leads, you're not leaving $50K on the table. You're leaving significantly more.

What the Agencies Don't Realize They're Losing

The raw dollar loss is painful enough. But the hidden cost is worse.

Here's what 93% of agencies never do with a lead: call back a second time. According to Agency Performance Partners, 93% of insurance leads are never called back even once after the initial attempt. Not twice. Once.

Leads360 dug deeper and found that 52% of insurance agents claim they never follow up with internet leads at all. Zero. The lead comes in, nobody picks up the phone, and that's the end of it. Another 44% stop after just one follow-up attempt. And across the industry, the average agency makes only 1.3 call attempts on internet leads.

One point three.

Think about what a prospect experiences. They visit your website at 10 PM on a Tuesday because their homeowners policy renewal is coming up and they want to shop rates. They fill out a form. They go to bed. The next morning, nothing. No call. No email. Maybe a generic auto-reply that says "we received your inquiry and will be in touch."

By noon, they've already called another agency. By Wednesday, they've bound a policy. And your agency — the one that paid for that lead — gets nothing.

That's not just a lost sale. That's a lost relationship. A lost referral chain. A lost online review. A lost opportunity for the prospect to tell three friends about how responsive and professional you are.

And the compounding effect is brutal. In a market where 78% of customers go with the first agent to respond, according to Insurance News Net, you're not just losing that one policy. You're training yourself to believe that internet leads don't work. You'll tell other agents that leads are "low quality." You'll reduce your spend or stop generating them altogether. Meanwhile, the agency down the street that invested in a five-minute response system is collecting the clients you paid to acquire.

What "Good" Looks Like: Speed-to-Lead Benchmarks

Let's reset expectations. Here's what fast response actually looks like for an independent agency:

The Gold Standard: Under 5 Minutes

Only 22.6% of agencies use technology to reach out to leads within the first minute, according to Leads360. That's your competition. If you can consistently respond to inbound leads within five minutes — whether that's a phone call, a text, or a personalized email — you're in the top tier of the industry. Not top 20%. Top 5%.

The Minimum Viable Response: Under 1 Hour

MIT's research is clear: the one-hour mark is the cliff. Below one hour, you're seven times more likely to have a real conversation. Above two hours, you're in freefall. If you can't hit five minutes, hit one hour. It's still dramatically better than the 47-hour industry average.

The Follow-Up Standard: 5-7 Touches

The single call attempt that 44% of agents stop after? It's not enough. Industry data consistently shows that it takes 5-7 follow-up attempts to reach a lead who hasn't responded. Most prospects aren't ignoring you — they're busy, distracted, or saw your message at a bad time. Each touchpoint is a coin flip. You need enough flips.

The Cadence: Day 0, Day 1, Day 3, Day 7, Day 14, Day 21, Day 30

That's a simple, repeatable follow-up sequence. Initial contact on Day 0. Follow-up the next day. Then spread the remaining touches over a month. Not aggressive. Not spammy. Just persistent enough to catch someone when they're ready.

The Fix: Practical Steps You Can Implement This Week

You don't need a massive technology overhaul. You need a system. Here's how to build one without disrupting your operation:

1. Audit Your Current Speed

Before you fix anything, measure it. Pull up your CRM or lead source and look at the last 50 inbound leads. How many did you call within five minutes? Within one hour? Within 24 hours? The number will embarrass you — and that's the point. You need a baseline.

2. Route Leads Immediately

The biggest bottleneck isn't willingness — it's routing. When a lead comes in through your website, it sits in an inbox or a form submission queue. By the time someone checks it, hours have passed. Set up automatic alerts that push lead information directly to a mobile device the instant it arrives. Email won't cut it. You need a text, a push notification, or a direct CRM ping.

3. Create a First-Call Script for Speed Leads

When you're calling someone within five minutes, you need a script optimized for speed, not a 15-minute consult. The goal is simple: confirm they're still shopping, get a time for a real conversation, and set the next touchpoint. That's it. Don't try to close on the first call. Try to start the relationship.

4. Build a Follow-Up Cadence and Stick to It

Use the Day 0, Day 1, Day 3, Day 7, Day 14, Day 21, Day 30 structure as your baseline. Automate what you can — text reminders, email sequences — but make sure a human touches each lead at least twice in the first 48 hours. The combination of automated persistence and personal outreach is what moves the needle.

5. Assign Ownership

Every lead needs a name attached to it within 60 seconds of arrival. Not a team. A person. When leads go to "the agency," nobody owns them. When they go to Sarah, Sarah calls within five minutes. Accountability is the simplest technology you can deploy.

6. Review Weekly

Every Friday, pull up the week's leads. How many came in? How many were contacted within five minutes? How many within an hour? How many received follow-up attempts beyond the first call? Reviewing this data takes 15 minutes and will transform your conversion rate faster than any software purchase.

The Compounding Effect of Getting This Right

Speed-to-lead isn't a tactic. It's a system that compounds.

Faster response means more conversations. More conversations mean more quotes. More quotes mean more policies. More policies mean more referrals. More referrals mean lower customer acquisition cost. Lower CAC means more budget for growth. It's a flywheel, and the spark is the first five minutes.

Most independent agencies will read this article and do nothing. The 52% who never follow up with internet leads aren't going to suddenly become responsive organizations because of a blog post.

But you're not most agencies. You're reading this because you already sense that the gap between where your agency is and where it could be is measured in tens of thousands of dollars per year. And you're right.

The question isn't whether slow response costs you money. The data is overwhelming. The question is whether you're going to fix it.

If you're an independent insurance agency and want to know your actual speed-to-lead numbers, I'm running free audits this month. No pitch, no obligation — just data. Get your free audit →

Sources:

Onyx CRM — Average response time data
Velocify — 5-minute response conversion rates (15M+ leads)
InsideSales.com / MIT — Follow-up timing vs. conversation outcomes
Agency Performance Partners — Lead follow-up statistics
Leads360 — Agency follow-up behavior analysis
Insurance News Net — First-responder market share data

I Built a 7-Agent System That Earns USDC Per Call — Here Are the 5 Skills That Matter Most

tinycoder-studio — Mon, 14 Sep 2026 22:23:23 +0000

Update 2026-09-15:* Machine reboot rotated our demo URL. New live endpoint: https://pose-textbooks-heroes-configure.trycloudflare.com. Bookmark the status page for the current URL — tunnel endpoints rotate. https://status-page-deploy.vercel.app/

I've been running a 7-agent AI system for weeks. It routes tasks, scans code for vulnerabilities, humanizes text, analyzes content — and now it earns USDC per API call via x402.

Here's what I built, what works, and the 5 skills you can steal.

The System

Seven specialist agents, each with a job:

Agent	Role
oracle	Supreme orchestrator — routes tasks
admin	Security, infrastructure, hardening
dev-worker	Code, builds, deployments
loki	Marketing, strategy, growth
product-reviewer	Compliance, content safety
navigator	Browser automation, scraping
graphic-artist	Image prompts
humanizer	AI text → natural human tone

They coordinate through a central oracle. You give it a task, it routes to the right specialist.

The Money Part: x402

x402 is an HTTP-native payment protocol. Client calls API → gets 402 Payment Required → pays USDC on Base → gets result. No Stripe, no auth, no invoicing.

I deployed 4 endpoints on a $0 Cloudflare Tunnel:

Endpoint	Price	Agent
`/api/oracle/route`	$0.001	oracle
`/api/humanize`	$0.005	humanizer
`/api/security-scan`	$0.01	admin
`/api/analyze`	$0.003	loki

Live at: https://pose-textbooks-heroes-configure.trycloudflare.com

The 5 Skills (Packaged for You)

1. Oracle Coordination — Task Routing

Routes any task to the right agent. Keyword-based, extensible, <1ms.


javascript
function routeToAgent(task) {
  const t = task.toLowerCase();
  if (/secur|malware|firewall/.test(t)) return { agent: 'admin', reason: 'Security' };
  if (/code|build|deploy/.test(t)) return { agent: 'dev-worker', reason: 'Code' };
  if (/market|strateg|growth/.test(t)) return { agent: 'loki', reason: 'Marketing' };
  // ... etc
  return { agent: 'oracle', reason: 'Orchestration' };
}
2. Security Scanning — 20+ Patterns
Catches hardcoded secrets, eval(), SQL injection, XSS, shell injection, privilege escalation.
const patterns = [
  { pattern: /password\s*[:=]\s*['"]?\w+['"]?/gi, type: 'Hardcoded password', severity: 'HIGH' },
  { pattern: /eval\s*\(/gi, type: 'Code injection (eval)', severity: 'MEDIUM' },
  { pattern: /SELECT.*FROM.*WHERE.*['"]/gi, type: 'SQL injection', severity: 'HIGH' },
  // ... 17 more
];
3. Text Humanization — 20+ Replacements
Turns "In today's digital landscape, it is important to note that we should utilize robust solutions" into "Today, Note that we should use strong solutions."
const replacements = [
  [/In today's digital landscape/gi, "Today"],
  [/it is important to note that/gi, "Note that"],
  [/utilize/gi, "use"],
  [/leverage/gi, "use"],
  [/furthermore/gi, "Also"],
  // ... 16 more
];
4. Content Analysis — SEO + Sentiment
Stats, top keywords, reading time, sentiment score.
function analyzeContent(text) {
  // Returns: { stats, top_words, sentiment_score, sentiment_label }
}
5. x402 API Builder — Deploy Your Own
250 lines, Node 16, zero deps. Deploy in 3 commands:
nohup node server.js > server.log 2>&1 &
cloudflared tunnel --url http://localhost:3000
# Copy the https://*.trycloudflare.com URL
The n8n Templates
Each skill has a ready-to-import n8n workflow:
- Webhook trigger → x402 payment → agent call → formatted response
- Slack alerts for high-severity findings
- SEO recommendations for content
- Metrics tracking for humanization
Import → Configure credentials → Deploy.
Revenue Reality
At current pricing:
- 100 calls/day across all endpoints = ~$57/month
- 1,000 calls/day = ~$570/month
Your revenue depends on distribution. The pack includes n8n templates so buyers can integrate instantly.
Get the Pack
$29 on Gumroad — Includes all 5 skills (markdown + code), 5 n8n templates (JSON), complete x402 server, docs, MIT license.
Agent Skills Pack on Gumroad (https://tinycoderstudio.gumroad.com/l/7-agent-skills-pack)

I Found an Undocumented MCP Server on OpenSea — and It Leaked Usernames for Any Wallet

tinycoder-studio — Sun, 13 Sep 2026 03:28:36 +0000

I Found an Undocumented MCP Server on OpenSea — and It Leaked Usernames for Any Wallet

TL;DR: OpenSea runs an undocumented MCP server at mcp.opensea.io/mcp. One of its tools hands out API keys to anyone who asks, and another lets you resolve any Ethereum address with an OpenSea profile to its owner's username. Reported to Bugcrowd, now sharing the story and a free recon kit.

The Setup

I was poking around OpenSea's tooling one afternoon — just trying to understand how some of their internal features worked. Nothing fancy, no scanners, no brute force. Just curiosity and a browser.

That's when I stumbled onto something that wasn't meant for public eyes: an undocumented MCP server sitting at mcp.opensea.io/mcp.

At first glance it looked like just another internal API. But one particular tool caught my attention: get_instant_api_key.

The Discovery

Turns out, that little endpoint was an unintended exposure of something far more valuable. By sending a straightforward POST request to https://api.opensea.io/api/v2/auth/keys, I could pull a valid API key straight out of the server. No authentication hoops — just a direct line to a credential that should have stayed hidden.

With that key in hand, I called the get_profile tool and, suddenly, I could look up a username for any Ethereum address with an OpenSea profile. I tested it on my own wallet, then on a well-known one. Both resolved instantly.

It felt like finding a master key to a building you weren't supposed to enter.

Why This Matters

Information disclosure like this isn't just a curiosity — it's a useful starting point for attackers. Enumerating usernames might seem harmless, but it's often the first step in mapping out a target's footprint:

Tie a wallet to a real identity (doxxing vector)
Correlate multiple wallets to one person
Build a profile for targeted phishing or social engineering

For NFT holders, that's a real privacy concern. Your wallet is supposed to be pseudonymous — this tool weakens that pseudonymity.

What OpenSea Did Right

To be fair, not everything on that server was exposed. The sensitive tools — like cancel_orders — properly required a wallet JWT with write:orders scope. Trying to call them without it returned a clean MISSING_SCOPE error.

So the architecture is sound. The gap was in the discovery layer: a handful of tools were reachable with just an API key that anyone could mint.

The Responsible Disclosure

I reported this to OpenSea's Bugcrowd program with a full write-up and PoC. It's now in their triage queue (self-assessed as P4 informational — username enumeration; official severity pending triage).

I have no affiliation with OpenSea or Bugcrowd.

If you're a security researcher: don't go poking at this yourself. It's been reported, and testing live systems without authorization is both against program rules and a great way to get banned.

The Free Recon Kit

I turned the whole investigation into a free PDF — the OpenSea MCP Server Recon Kit — with the methodology, the tools I enumerated, and the lessons learned. It's pay-what-you-want (free, $0 minimum), and it's the same playbook I use when auditing any undocumented API surface. The kit contains methodology only — no exploit code:

👉 Download the free recon kit

The Bigger Lesson

Undocumented internal APIs are everywhere. They're often overlooked during security reviews, yet they can leak exactly the kind of secrets — like API keys — that turn a minor misconfiguration into a real problem.

The next time you're auditing a target, ask yourself: what endpoints exist that nobody documented? That's where the interesting stuff hides.

This technique was reported to Bugcrowd and is shared here for educational purposes only.

Found this useful? Follow me for more bug bounty write-ups and recon methodology.

I Found an Undocumented MCP Server on OpenSea — and It Leaked Usernames for Any Wallet

tinycoder-studio — Sat, 12 Sep 2026 23:52:09 +0000

The Setup

I was poking around OpenSea's tooling one afternoon — just trying to understand how some of their internal features worked. Nothing fancy, no scanners, no brute force. Just curiosity and a browser.

That's when I stumbled onto something that wasn't meant for public eyes: an undocumented MCP server sitting at mcp.opensea.io/mcp.

At first glance it looked like just another internal API. But one particular tool caught my attention: get_instant_api_key.

The Discovery

It felt like finding a master key to a building you weren't supposed to enter.

Why This Matters

Information disclosure like this isn't just a curiosity — it's a goldmine for attackers. Enumerating usernames might seem harmless, but it's often the first step in mapping out a target's footprint:

Tie a wallet to a real identity (doxxing vector)
Correlate multiple wallets to one person
Build a profile for targeted phishing or social engineering

For NFT holders, that's a real privacy concern. Your wallet is supposed to be pseudonymous — this tool quietly erases that.

What OpenSea Did Right

So the architecture is sound. The gap was in the discovery layer: a handful of tools were reachable with just an API key that anyone could mint.

The Responsible Disclosure

If you're a security researcher: don't go poking at this yourself. It's been reported, and testing live systems without authorization is both against program rules and a great way to get banned.

The Free Recon Kit

👉 Download the free recon kit

The Bigger Lesson

The next time you're auditing a target, ask yourself: what endpoints exist that nobody documented? That's where the interesting stuff hides.

This technique was reported to Bugcrowd and is shared here for educational purposes only.

Found this useful? Follow me for more bug bounty write-ups and recon methodology.

I Rewrote 5 AI-Generated Paragraphs to Sound Human — Here's the Before & After

tinycoder-studio — Thu, 10 Sep 2026 00:13:37 +0000

Last week I wrote about building an AI humanizer that actually sounds human. @topstar_ai pointed out the hardest challenge — and they're right. The hardest part isn't making AI text longer. It's making it feel like someone actually meant what they wrote.

Here's what I found.

1. Uniform rhythm. Every sentence is 12-18 words. Humans vary wildly — some thoughts are three words, others spill across two sentences.

2. Hedging and filler. "It's important to note that..." "In today's world..." These phrases add zero meaning and scream template.

3. Empty transitions. "Furthermore," "Moreover," "Additionally" — humans say "also" or just skip the transition entirely.

None of these are wrong. They're just empty. And once you spot them, you can't unsee them.

1. Product description (generic SaaS pitch)

AI: Our platform provides a comprehensive suite of tools designed to help teams collaborate more effectively and streamline their workflow.
Human: It helps teams stop chasing each other across Slack threads.

Annotation: Cut the feature list. Gave it a problem and a punch.

2. Blog intro (the classic "In this article, we'll explore...")

AI: In this article, we will explore the top trends shaping the future of web development in 2025 and beyond.
Human: Web dev moved fast in 2024. Here's what actually mattered.

Annotation: Killed the meta-commentary. Started mid-thought like a human would.

3. Social media post (LinkedIn thought-leadership)

AI: Furthermore, it is important to recognize that leadership in today's world requires adaptability and a commitment to continuous learning.
Human: Adapt or die. That's been true forever — but most people still skip the uncomfortable part.

Annotation: Removed "furthermore" and "it is important to recognize." Added an opinion.

4. Email outreach (cold template)

AI: I hope this message finds you well. I am reaching out to introduce our product, which I believe could be of great value to your organization.
Human: Your site's load time is 4 seconds. Here's how to cut it to 1.

Annotation: No greeting, no filler. Led with a specific number they can't ignore.

5. Error message / technical explanation

AI: An unexpected error has occurred. Please try again or contact support if the issue persists.
Human: Something broke on our end. We're fixing it — refresh in 30 seconds and it should work.

Annotation: Added a timeframe and ownership. Humans explain what's happening and when it ends.

Human writing has opinions, rhythm changes, and friction. AI writing is smooth, safe, and forgettable.

That's the whole game. If you're tired of generating text that reads like a committee wrote it, check out PseudoHuman at toolbox-lilac-three.vercel.app — it takes your AI draft and injects the personality it's missing.

What's the tell-tale sign that makes you stop reading something that sounds AI-generated?

I'm Building an AI Humanizer That Actually Sounds Human — Here's What I'm Learning

tinycoder-studio — Wed, 09 Sep 2026 14:22:02 +0000

Hey — I'm building an AI humanizer in public, and I wanted to share what I'm learning before there's anything to launch.

The problem I'm seeing

Most "humanizers" I've tried just swap synonyms. You know the output instantly:

"Utilize" instead of "use." Perfect grammar. Zero rhythm. Every sentence the same length.

It passes a thesaurus check and fails the human check. Real people write messy — fragments, dashes, short punches after long rambles. That's what I'm trying to capture.

What I'm building (honestly, still early)

No beta yet. No launch. I'm building a small tool that rewrites AI-sounding text so it aims to sound like a person wrote it — rhythm, burstiness, tone shifts, not just word swaps.

Right now I'm just testing in the open and learning from real examples.

What surprised me so far

Rhythm beats vocabulary. Varying sentence length does more for "sounds human" than any synonym swap.
Imperfection is a feature. A fragment. An em dash. A blunt short sentence. Readers trust it more.
Context matters more than cleverness. Same input needs a different rewrite for an essay vs. a tweet vs. an email.

A tiny before/after (from my own testing notes, still rough)

Before (typical AI):

"In today's fast-paced world, it is important to utilize effective tools for content creation."

What I'm aiming for:

"Everyone's drowning in AI-sounding content. I'm trying to make mine sound like I actually wrote it."

Still rough. That's the point of building in public.

What I want from you

Drop a sentence that screams AI in the comments — I'll reply with how I'd approach rewriting it, and what I'd still get wrong. Teaching in the open, learning in the open.

If you want a note when the early access list opens, follow along. No spam, just the build log.

Vanilla JavaScript PWA Tutorial: Build With Zero Dependencies

tinycoder-studio — Mon, 07 Sep 2026 10:05:39 +0000

Every PWA tutorial starts with "install React, then Next.js, then configure Webpack..." By the time you're done, you have 200MB of node_modules for a to-do app.

This tutorial uses zero dependencies. Just HTML, CSS, and JavaScript. You'll have a working PWA in 10 minutes.

What We're Building

A simple web app that:

Works offline
Installs to the home screen
Has a service worker for caching
Runs on any static host (Vercel, Netlify, GitHub Pages)

Step 1: The HTML

Create index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>My PWA</title>
  <link rel="manifest" href="/manifest.json">
  <meta name="theme-color" content="#0F172A">
  <link rel="apple-touch-icon" href="/icon-192.png">
</head>
<body>
  <h1>Hello, PWA!</h1>
  <p>This app works offline.</p>
  <script src="/app.js"></script>
</body>
</html>

Step 2: The Manifest

Create manifest.json:

{
  "name": "My PWA",
  "short_name": "PWA",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#0F172A",
  "theme_color": "#06B6D4",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

Step 3: The Service Worker

Create sw.js:

const CACHE = 'my-pwa-v1';
const ASSETS = ['/', '/index.html', '/app.js', '/style.css'];

self.addEventListener('install', e => {
  e.waitUntil(
    caches.open(CACHE).then(cache => cache.addAll(ASSETS))
  );
});

self.addEventListener('activate', e => {
  e.waitUntil(
    caches.keys().then(keys =>
      Promise.all(keys.filter(k => k !== CACHE).map(k => caches.delete(k)))
    )
  );
});

self.addEventListener('fetch', e => {
  e.respondWith(
    caches.match(e.request).then(r => r || fetch(e.request))
  );
});

The service worker does three things:

Install — caches all app files
Activate — deletes old caches
Fetch — serves from cache, falls back to network

Step 4: Register the Service Worker

Create app.js:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js')
    .then(reg => console.log('SW registered:', reg.scope))
    .catch(err => console.log('SW failed:', err));
}

Step 5: Deploy

If you're using Vercel:

npm i -g vercel
vercel deploy --prod

That's it. Your PWA is live.

Testing Offline

Open Chrome DevTools → Application → Service Workers
Check "Offline" in the Network tab
Refresh the page — it should still load
On Android: three-dot menu → "Add to Home Screen"

Why Vanilla JS?

Zero dependencies — nothing to update, nothing to break
Fast — no build step, no transpilation
Small — the entire app is under 10KB gzipped
Understandable — you can read every line

React and Next.js are great for complex apps. But for a simple PWA? Vanilla JS is enough.

Want a head start?

TinyCoder is a vanilla JS PWA with 5 offline dev tools. Config-driven, deployable in minutes.

Originally published at toolbox-lilac-three.vercel.app/blog/vanilla-js-pwa-tutorial.html