Forem: Bishwas Bhandari

I built a LinkedIn MCP server for Claude in a weekend. Here's the Python + Playwright pattern.

Bishwas Bhandari — Mon, 04 May 2026 03:43:23 +0000

The LinkedIn Marketing API is enterprise-gated. Phantombuster wants $69/mo. The cookie-paste shortcut on Stack Overflow breaks within four requests. SuperMCP solves this with Playwright and your real Chrome session. Here's the architecture plus the prompt patterns I use weekly.

TL;DR

I run a forum at webmatrices.com where indie founders post about their SaaS bottlenecks. A lot of the same complaints surface on LinkedIn, in the comments under bigger founder posts. I wanted Claude to cross-reference both. The cleanest path turned out to be a LinkedIn MCP server that reuses your Chrome login session via Playwright. No API key, no third-party cloud, nothing leaves your laptop.

Code's at github.com/Bishwas-py/supermcp. MIT-licensed. Install is pip install supermcp && supermcp setup. The LinkedIn-specific docs are here.

If you just want the working setup, skip to the architecture section. If you want to know why the cookie-paste shortcut fails, keep reading.

The naïve approach (and why it breaks)

Before SuperMCP existed, I did the dumb thing one weekend. I opened LinkedIn in Chrome, opened devtools, copied my li_at cookie out of Application > Cookies, and pasted it into a Python script using httpx:

cookies = {"li_at": "AQED...redacted..."}
r = httpx.get("https://www.linkedin.com/voyager/api/me", cookies=cookies)

That worked. I got a clean JSON response with my own profile data. I felt clever for about ninety seconds.

Then I tried the search endpoint. voyager/api/graphql/... returned 999 Forbidden. Tried again. 999 again. Within four requests, LinkedIn sent a 2FA email to my real address: "We noticed an unusual sign-in attempt." No sign-in had happened. The script was using my session cookie. The challenge fired anyway.

The reason: LinkedIn's anti-abuse system isn't just looking at cookies. It's looking at TLS fingerprints, JA3 signatures, the order of HTTP/2 headers, the User-Agent/Accept-Language combo, and a few dozen other things that make a real Chrome request look like a real Chrome request. httpx doesn't lie about being httpx, even with a stolen cookie. Once the fingerprint was wrong, the cookie became evidence rather than authentication.

So copying cookies into a script is the correct mental model and the wrong implementation. The fix is: don't copy the cookie. Make a real browser do the request. Which is what a headless Chromium with persistent storage state actually is.

The architecture that worked

Three layers, nothing fancy:

Claude / Cursor  ←stdio→  MCP server (Python + FastMCP)
                            │
                            └── Playwright (headless Chromium
                                  with persistent storage state)
                                  │
                                  └── linkedin.com (your real session)

The trick is persistent storage state. Playwright lets you point a Chromium instance at a directory containing cookies + localStorage + IndexedDB from a previous session. That session can be one Playwright created earlier (run it once, log in by hand, save state to JSON), or in some configs you can clone a directory off your real Chrome profile. Either way, the resulting browser is real. The TLS fingerprint is real. The JA3 is real. The header order is real. LinkedIn sees a logged-in user opening their search page in Chrome, which is what's actually happening.

After that, FastMCP wraps the tools in about 20 lines of glue per tool:

from fastmcp import FastMCP

mcp = FastMCP("supermcp")

@mcp.tool()
async def linkedin_search(query: str, limit: int = 20) -> str:
    """Search LinkedIn posts. Returns markdown with author, reactions, URL."""
    page = await browser.new_page()
    await page.goto(f"https://www.linkedin.com/search/results/content/?keywords={query}")
    # parse results from the rendered DOM
    ...
    return format_as_markdown(results)

A few things I learned the hard way once I had it working:

Return markdown, not JSON. Models read markdown faster (about 30% fewer tokens, in my testing on Claude 4.6) and they chain follow-up calls more reliably when IDs and URLs are surfaced as plain text rather than buried in nested objects. I have a small format helper that always emits stable IDs in **id:** abc123 form so Claude can call linkedin_post_comments(post_id="abc123") after a search.

Be honest in tool descriptions. Claude routes tool calls based on the docstring you give the MCP server. If your description is vague, Claude will use it for the wrong intent. linkedin_search is post search by keyword, not people search, so the docstring says exactly that. People search needs a different tool, which I don't ship because LinkedIn flags it harder.

Cap the per-day request budget at the MCP layer. Not at the LinkedIn layer. The reason is that Claude will sometimes loop, burning through 40 search calls trying to refine a query that was wrong from the start. Catching that at the MCP server (one shared counter, not per-tool) is much cheaper than letting LinkedIn catch it.

The three tools, and the prompts that actually work

The whole LinkedIn surface is three tools.

`linkedin_search` (the workhorse)

This is what I use 90% of the time. Keyword search across all public LinkedIn posts. Pain-point mining looks like:

Search LinkedIn for posts where solo founders complain about Stripe billing edge cases. Pull the top 25, group by complaint pattern, surface the top three with example URLs.

Claude calls linkedin_search, gets back markdown, synthesizes. The synthesis step is where the value compounds. Claude is much better at clustering complaints than I am at reading 25 posts in a row.

Two prompt patterns that work consistently for me:

"Group by pattern, then surface 3." Claude is bad at "summarize this," good at "cluster then rank." Asking for clustering first gives you a much more useful synthesis.
"Quote the most concrete one." Adding "include one literal quote from the most concrete-sounding post" at the end of the prompt forces Claude to actually pick a post rather than confabulate a synthesis. Quotes are a forcing function for groundedness.

`linkedin_feed` (for taking the temperature)

Pulls your algorithmic home feed. Good for "what is my actual network talking about today?", useful when you want a less-curated read. I don't use it for research; I use it for context-setting before I post.

`linkedin_post_comments` (the underrated one)

Reads the comment thread on a specific post URL. People underrate this because they think the post is the signal. The post is usually marketing. The signal is in the comments, where the post's audience says what actually shipped vs. what was promised. If a founder posts "we hit $1M ARR with 3 people," the comments will sometimes have a former employee or a competitor adding important context. That's the data you want.

How SuperMCP keeps accounts under the radar

This is the part I cared most about figuring out before shipping. After the cookie-paste shortcut taught me how LinkedIn's anti-abuse stack works, I designed SuperMCP around six practices that have kept my main account clean over the last 6 months of daily use:

Real browser, not headless flag. Playwright with headless=False for the first session, then headless=True in production. Some bot detection looks specifically at the headless Chrome boolean.
One request at a time. No parallelism. If Claude wants 25 results, I serve them one fetch at a time, with a 1.5–3s jitter between actions. LinkedIn cares more about pace than volume.
Reuse the session. Don't launch a new browser context per request. Reusing one warm session looks human; spawning fresh contexts looks scripted.
No people search. Post search and feed reading are common user actions. People search at scale isn't, and LinkedIn flags it. I just don't ship the tool.
Daily budget cap, low default. Free tier is 100 requests/day. That's about 3x normal human activity in a research session, well below anything LinkedIn flags as automation.
Bail fast on challenges. If the page returns a captcha, a 2FA prompt, or even a soft "is this you?" check, SuperMCP stops the run, logs it, and backs off for 24 hours. Almost every flag escalation comes from tools that retry through challenges instead of standing down.

For context on why this matters: LinkedIn migrated their post composer from ProseMirror to Quill earlier this year and broke practically every browser-automation tool that touched the editor. They're actively updating selectors and fingerprints. A maintained tool will weather these changes. A frozen one won't.

How this stacks up against the alternatives

Approach	Cost	Setup	Where it runs	Weakness
SuperMCP (LinkedIn MCP)	Free / $9 one-time	`pip install`	Your laptop	DOM changes break things; needs maintenance
LinkedIn Marketing API	Free if approved	Months of partner approval	Your server	Indie founders don't get approved
Phantombuster	$69/mo	Cookie hand-off to their cloud	Their cloud	Third party operates on your account
Apify / Bright Data	Pay per result	Actor + budget	Their cloud	Costs unpredictable at scale
DIY Selenium + cookies	Free	Days of selector wrangling	Your laptop	The naïve version of this is the cookie-paste shortcut. Breaks fast.

The honest case for SuperMCP isn't that it's strictly better than all of these. The Marketing API is the right answer if you can get approved. Phantombuster is the right answer if you don't want to think about it. SuperMCP is the right answer if you (a) can't get the API, (b) don't want to send your cookies to a third-party cloud, and (c) want it talking directly to Claude or Cursor instead of a separate dashboard.

Installing it

pip install supermcp
supermcp setup           # gets your API key, auto-installs Chromium
claude mcp add supermcp -- supermcp

Cursor users, drop this in settings.json:

{ "supermcp": { "command": "supermcp" } }

After that, ask Claude things like:

Find LinkedIn posts where someone is complaining about Stripe Checkout. Group by complaint, surface 3 with quotes.
Pull the top comments on this LinkedIn post: [URL]. Where do commenters disagree with the OP?
Cross-reference my LinkedIn feed against Reddit's r/SaaS. What's in both?

The third one needs the Reddit MCP too, which is the same package.

Why I bundled this with Reddit, Twitter, and the rest

Halfway through the LinkedIn build, I realized the same Playwright-with-persistent-state trick worked for Reddit (where the API is now paid and rate-limited), Twitter/X (where the cheapest tier is $200/mo), Medium, Dev.to, BlackHatWorld, and Google Trends/News. By the end of the second weekend I had 26 tools across 7 sources, all using the same auth pattern. The bundle is called SuperMCP. One install, all sources. Repo: github.com/Bishwas-py/supermcp.

If you only need LinkedIn, you only call the LinkedIn tools. The other platforms don't activate unless you use them.

FAQ

Is this safe for my LinkedIn account?
Yes, with the defaults SuperMCP ships. The free-tier rate cap (100 requests/day) sits well under any threshold LinkedIn flags as automation, and the Playwright setup uses your real browser fingerprint instead of a stripped-down httpx request, so the traffic looks like a normal logged-in user. I've run this on my main account daily for 6 months without a flag. The one caveat: a brand-new LinkedIn account doing aggressive research will draw attention faster than an established one, so stick to the defaults until you have a feel for it.

Is this against LinkedIn's TOS?
LinkedIn's User Agreement prohibits "automated software" against the service. Same is true for X, Reddit, and Medium. The practical situation is that every browser-automation tool (Phantombuster, Apify, this) operates in that gray zone, as does every personal-productivity Chrome extension you've installed. SuperMCP runs locally at human-scale rates with your own session. I'm not your lawyer. The repo has a TOS notice, use accordingly.

Does the Reddit / Twitter / Medium MCP need an API key?
No. Same Chrome-session trick. Reddit's API is now paid; Twitter's cheapest tier is $200/mo; Medium has no read API. All three work via your existing logged-in session.

Which AI tools support this?
Any MCP-compatible client: Claude Desktop, Claude Code, Cursor, Windsurf, Cline, GitHub Copilot Agent, Continue. SuperMCP is a standard stdio MCP server.

Where do I get an API key?
supermcp setup after pip install supermcp. Free tier (100 requests/day) is automatic. Unlimited tier is $9 one-time at webmatrices.com/supermcp.

If you build something on top of this, I'd love to see it. Drop an issue or a PR at github.com/Bishwas-py/supermcp. The LinkedIn-specific docs are at webmatrices.com/supermcp/linkedin-mcp.

I built a free backlink suggester for indie founders. Here is what 4 weeks of audits taught me.

Bishwas Bhandari — Wed, 29 Apr 2026 06:27:13 +0000

About a month ago I added a feature to Webmatrices called the Backlink Suggester. It is a guided form. A founder picks a category (guest posts, resource pages, competitor backlinks), describes their challenge, drops their site URL, and posts to the community. I review every one personally, and the community chimes in too. Free for the public version. $3 for a private audit if they want it kept off the public feed.

The reason I built it was specific. Every week I was getting the same DM on Webmatrices. "Hey can you take a look at my site and tell me where I should be looking for backlinks." After the third or fourth time, I realized that question deserved a structured tool, not a one-off DM thread.

Four weeks in, I have written audits for a Japanese name generator competing against Shopify's tool, a personal finance blog on Blogger trying to figure out why guest pitches kept failing, an F-1 visa interview prep tool with seven blog articles trying to find study-abroad backlinks, and a multi-niche utility platform with 90+ tools trying to figure out which cluster to lead with for backlink outreach. Different niches, different sets of advice, all starting from the actual specifics of the site instead of a generic checklist.

This post is a writeup of what I learned, what surprised me, and the architecture of how it is built.

how it actually works

The tool is a 5-step form. Pick a category (guest posts, resource pages, competitor backlinks). Pick the specific challenge inside that category. Tell me your situation. Pick what kind of feedback you want. Drop your URL. The free path goes public on the Webmatrices feed and the community plus me reply on it. The $3 path goes private, just the user and me.

The dual tier exists because audits take real time. I write a 1000+ word reply per case. Scaling that without a small commercial backstop would not work, and I did not want the public version to disappear behind a paywall. The $3 number is intentional. Low enough that anyone who actually wants targeted advice can afford it. High enough to filter out drive-by submissions that would burn audit time.

the four patterns I keep seeing

After about 20 audits, I have a working list of what founders consistently get wrong.

The "scattered niche" trap. Multi-tool platforms cannot pitch as "a tools website" because editors do not know what category to put them in. The fix is pitching each cluster separately. SEO tools to digital marketing blogs. Islamic tools to Muslim lifestyle sites. Car calculators to automotive blogs. Same site, different angles. Most people do not realize this until I point it out.

The "pitch a stranger" assumption. Cold outreach response rates have collapsed to about 4% on average across the industry. People keep trying harder at the thing that used to work. The actual move is community presence over broadcast outreach. Founders showing up on Reddit, Indie Hackers, and dev forums consistently for six months get backlinks naturally because the community starts citing them when relevant questions come up. The ones still cold-pitching get nothing.

The "directory submissions are tier 3" fossil. Five years ago directories were considered low-quality filler. Today they are the easiest authority play for new sites because they are the one channel that does not depend on a human gatekeeper saying yes. One audit subject submitted to about 200 startup directories in his first month, hit DA 19 in 60 days, and that authority foundation was the reason his content started ranking nine months later.

The "competitor backlinks" rabbit hole. People come in asking for full competitor backlink analysis but what they actually need is to identify the 3-5 sites their competitors get links from that are realistic for them to also approach. The framing matters more than the data dump. The Ahrefs free tier is enough for the question being asked.

what surprised me

I expected the audits to be similar across niches. They are not. Every niche has its own unwritten rules, and the strategy that worked for a finance blog (HARO replacements + resource page outreach) is the wrong move for a Japanese name generator (anime and worldbuilding community placements) which is the wrong move for an F-1 visa prep tool (university .edu outreach + immigration consultant directories).

I also expected the $3 tier to barely matter. It does. People who pay $3 are dramatically more likely to actually act on the advice. I think the $3 functions as a commitment device, not a price.

The thing I did not expect: I am writing better audits because I review them publicly. Every public audit gets read by other community members and the next person submitting reads my last few audits before posting. That has changed how I write. The audits are more structured, more specific, and have less filler than they did when I was just sending one-off DMs.

what is on the roadmap

Three things I want to add. None of them are urgent, all are obvious.

A "search past audits" view, so people can browse audits in their niche before submitting their own. Right now the audits are scattered across the forum's digi-work tag, which is mixed with other content. A dedicated index would help.

A simple analytics view for premium users showing what the audit predicted vs what they actually did vs what their backlink count looked like 60 days later. Closing the feedback loop.

A "second opinion" feature where another experienced community member can volunteer to review the same audit and offer a different angle. Right now I am the only one writing audits for premium subscribers. Adding peers would scale better.

the meta-point

Indie devs and small SaaS founders have a backlink-help problem and the existing market is mostly $129/mo SaaS tools that show data but not strategy. The gap is human-to-human advice on specific situations. A community plus an admin who actually writes audits fills that gap at $3 instead of $129.

I am not claiming this is going to scale to millions of users. It is more like a help desk that happens to be public. But the specific niche, "small founders who need targeted backlink advice they cannot get from a tool dashboard," is real and underserved.

If you want to try it, the tool is at webmatrices.com/backlink-suggester. Free version works without signup. Drop your context in. I will write you back, usually within a day.

I Stopped Fighting the Reddit API, So I Built SuperMCP to Read It for Me

Bishwas Bhandari — Sat, 25 Apr 2026 13:15:34 +0000

Last year I was trying to add Reddit research to my Claude Code workflow. Seemed straightforward. Then I spent an afternoon registering an OAuth app, managing token refresh, and watching my script hit rate limits after 10 requests. Tried PRAW next, same wall. Tried raw scraping, it broke within a week when Reddit changed their markup.

I stepped back and thought: I'm already logged into Reddit in Chrome. Why can't my AI tools just use that session?

That's how SuperMCP started.

What It Actually Does

SuperMCP is an MCP server (Model Context Protocol, Anthropic's open standard for connecting AI tools to data sources). It gives Claude, Cursor, Windsurf, or any MCP-compatible tool access to:

Reddit: search posts, read full threads with comments, browse subreddits, check user activity
Twitter/X: search tweets, get reply threads, pull user timelines
Google Trends: real-time trending topics by region
Google News: search articles, top headlines, topic-filtered news

13 tools total, all running on your machine as a local process.

The Trick: Your Chrome Login Session

Here's what makes this different from every Reddit scraper tutorial on dev.to.

SuperMCP reads cookies from your Chrome browser's local database, the same way password managers do. It spins up a headless Chromium instance that browses Reddit and Twitter as you. You don't need API keys for Reddit or Twitter, don't need to register an OAuth app, don't need to deal with token refresh.

You (logged into Reddit in Chrome)
        ↓
Chrome's cookie database (on your disk)
        ↓
SuperMCP reads cookies locally
        ↓
Headless Chromium browses as you
        ↓
Results returned to Claude/Cursor via MCP

Google Trends and News use public RSS feeds directly. No login, no browser, instant results.

Your data never leaves your machine. The only external call is API key validation to webmatrices.com.

Setup: 3 Commands

pip install supermcp
supermcp setup          # paste your API key, auto-installs Chromium
claude mcp add supermcp -- supermcp

That's it. If you use uvx:

uvx --from supermcp supermcp setup
claude mcp add supermcp -- uvx --from supermcp supermcp

For Cursor, add to .cursor/mcp.json:

{
  "supermcp": { "command": "supermcp" }
}

Get your free API key at webmatrices.com/supermcp. 100 requests/day on the free tier, unlimited for a one-time $9.

What This Looks Like in Practice

Once installed, you just talk to Claude normally. Here are prompts I use:

Market research before building a feature:

"Search Reddit for posts about 'invoice automation for freelancers'. What are people actually complaining about?"

Claude calls reddit_search, pulls real threads with real comments, and summarizes the pain points. No copy-pasting URLs, no switching tabs.

Monitoring competitor sentiment:

"Search Twitter for mentions of [competitor] from the last week. What's the general sentiment?"

Trend validation:

"What's trending on Google Trends in the US right now? Anything related to developer tools?"

Deep-dive on a thread:

"Get this Reddit post with all comments: [url]. Summarize the key takeaways and any tools people are recommending."

Content research:

"What's hot on r/SideProject this week? Any common themes?"

The 13 Tools

Tool	What It Does
`reddit_search`	Search all of Reddit
`reddit_get_post`	Full post + comments
`reddit_get_subreddit_posts`	Browse any subreddit (hot/new/top)
`reddit_search_subreddit`	Search within a subreddit
`reddit_get_user_activity`	A user's recent posts & comments
`twitter_search`	Search tweets
`twitter_get_tweet`	Tweet + full reply thread
`twitter_get_user_tweets`	Recent tweets from any account
`trends_get_trending`	Real-time trending by region
`news_search`	Search Google News
`news_top`	Top headlines
`news_by_topic`	News by category
`trends_interest_by_region`	Regional interest for any term

(and constantly adding new MCP for linkedin, Medium, Dev.to, and other social platforms)

Why Not Just Use the APIs Directly?

I tried. Here's what happened:

Reddit API: Free tier is heavily rate-limited. The paid Data API charges per request, and it adds up fast when your AI agent makes dozens of calls per conversation. You also need to register an app, manage OAuth tokens, handle refresh flows. I got it working once, and then spent more time maintaining the auth than actually using the data.

Twitter/X API: The free tier only lets you post tweets. Reading requires the Basic tier at $100/month. The Pro tier is $5,000/month. For a developer tool that just needs to search tweets? Absurd.

Google Trends: No official API exists. The popular pytrends library reverse-engineers Google's internal endpoints and breaks regularly.

SuperMCP sidesteps all of this. You're logged into Reddit and Twitter in Chrome already. SuperMCP just uses that session.

FAQ

Do I need Chrome open?
No. SuperMCP reads cookies from Chrome's database on disk. Chrome doesn't need to be running.

Does it work on macOS?
Yes. On first run, macOS will ask for your login keychain password to read Chrome's cookies. This is the standard macOS security prompt. Click "Always Allow" so it doesn't ask again.

Can I use this with tools other than Claude?
Any MCP client works. Claude Desktop, Claude Code, Cursor, Windsurf, Cline, and anything else that supports the MCP protocol.

What about Firefox or other browsers?
Chrome only for now. Firefox stores cookies differently and would need a separate integration.

Is this scraping?
SuperMCP browses Reddit and Twitter as you, using your authenticated session in a headless browser. It's equivalent to you opening a tab and reading the page yourself.

PyPI: pypi.org/project/supermcp · Python 3.10+ · macOS / Windows / Linux

If you're building with MCP servers, I'd be curious what data sources you wish you had access to. Drop a comment.

Gemma4 vs Claude Code: I Tried the Switch. Here's What Broke First.

Bishwas Bhandari — Mon, 20 Apr 2026 01:35:33 +0000

Every few months someone drops a new open model and the local AI community collectively loses their minds. "This is the one. This kills the subscriptions." It happened with Llama 3. With Qwen. With Gemma 3.

None of them actually did it.

So when Gemma 4 landed and the numbers looked genuinely scary, I decided to stop theorizing and just try it — wired into my actual dev workflow, building actual software. Not chat. Not benchmarks. Shipping code.

Here's what happened.

What Made This Test Worth Running

I'll be honest: I almost didn't bother. I'd been burned too many times by models that looked great in a playground and fell apart the second I asked them to do real work.

But Gemma 4's numbers are different. 31B parameters, #3 on Chatbot Arena, Apache 2.0 license, runs on a single GPU. Someone got it running on a 6GB phone. A developer built an Android automation agent with it before the week was out. The 26B MoE variant hits 80–110 tokens per second on an RTX 3090.

And here's the number that actually convinced me to test it: the τ²-bench agentic tool-use score. Gemma 3 scored 6.6% on that benchmark — meaning it failed 93 out of 100 tool calls. Basically useless as an agent. Gemma 4 31B scores 86.4% on the same test. That's not a marginal improvement. That's an entirely different model category.

So I tested it. And I kept notes.

The First 4 Hours Are Genuinely Impressive

Single-file edits? Fast and accurate. Writing fresh functions from scratch? Solid. It understood what I was asking, gave clean code, and didn't hallucinate imports.

Speed alone made me want this to work. No API latency. No waiting. Just results.

But then I gave it a real task.

Where It Broke

I asked it to refactor a module that touched 4 files. Nothing exotic — just a cleanup that involved renaming a function and updating its callers.

Here's what happened:

File 1: Edited perfectly. I was impressed.
File 2: Hallucinated the path. Generated changes to a file that didn't exist at that location.
File 3: Wrote code that called the function it had just deleted in File 1.

Classic context collapse. The model understood the task. It just couldn't hold the thread across multiple files under load.

I went back to Claude Code. Same refactor. One shot. Done.

That's the gap right now — and it's not about intelligence.

The Tool Calling Problem Is Worse Than the Benchmarks Suggest

Here's the thing about that 86.4% τ²-bench score: it's for the 31B Dense model. Most people running Gemma 4 on consumer hardware are using the 26B MoE variant — because it's faster and fits in less VRAM.

That model scores 68% on the same agentic benchmark. Qwen's comparable variant scores 81%.

In a 15-step workflow, a 68% tool-call success rate isn't a stat. It's a guarantee of failure somewhere in the middle.

I ran a test that made this painfully obvious. I asked Gemma 4 to scaffold a SvelteKit project — search the web for the latest setup command, then build it. Simple, explicit instructions. It said it couldn't access the web. I pointed it at a GitHub link. It said it couldn't open URLs. I pointed it at an MCP tool that was literally already connected and listed in its available tools.

It asked me for clarification instead of using the tool.

The same prompt, sent to a different model, returned a web search, a shell command, and a running project. No hand-holding needed.

(The side-by-side screenshots from the developer community testing this are wild — you can see both responses in our forum thread linked below. One says "I can't access that." The other just builds the thing.)

There's Hidden Performance That Hasn't Shipped Yet

This is where it gets interesting.

Some researchers digging through Gemma 4's model weights found undocumented multi-token prediction heads baked into the architecture. Speculative decoding, essentially — just not officially enabled. Google confirmed the finding but said it's "not yet officially supported."

So there's raw performance sitting in the model that nobody can use yet.

If they release proper MTP support alongside tool-calling fixes in a point release, the numbers improve significantly. And that's before mentioning the Ollama bugs that are tripping people up on Apple Silicon right now — a streaming bug that routes tool-call responses to the wrong field, and a Flash Attention freeze on prompts over 500 tokens.

These are fixable. The question is when.

What Claude Code Actually Does That's Hard to Replace

People frame this as a capability question. It's not. It's a reliability question.

Claude Code isn't the best model on any single benchmark. What it does is boring things consistently — reads your files, understands what's already in your codebase, calls tools in the right sequence, and doesn't lose the thread halfway through a 50-step workflow.

One developer I spoke with said it best: working with Gemma 4 on an existing codebase felt like pairing with a smart contractor who refuses to read the existing code. Technically correct suggestions, all of them wrong for this project.

That's not a parameter count problem. It's a training problem. And it's hard to fix.

So What Actually Happens to the Subscription Economy?

Here's my actual prediction, not the polite one:

Gemma 4 eats ChatGPT's casual usage hard. If you're using a subscription for summarizing stuff, answering questions, writing emails — Gemma 4 running locally is free and nearly as good. That category is gone.

But agentic coding is a different product. Maintaining context across 50 files, calling 15 tools in sequence, not hallucinating paths at 2am when you're exhausted — that's not what benchmarks test, and it's not what Gemma 4 is reliably doing yet.

The smart move right now is probably hybrid: Gemma 4 for the 80% of tasks that are fast and straightforward. Claude Code for the 20% that need depth and reliability. Especially for enterprises with data residency requirements — Apache 2.0 means you can finally run a capable model entirely on your own infrastructure.

The "one model" framing is wrong. It's becoming a stack.

The Conversation Developers Are Actually Having

I wrote a longer version of this take in our community forum and the responses were more honest than anything I've seen in a formal comparison. Real developers. Real workflows. Real failure modes.

One person tried switching for a weekend and lasted 4 hours. Another found the MTP heads in the weights. Another showed the side-by-side screenshots of Gemma 4 refusing to use available tools while a different model just executed.

That thread is here → webmatrices.com/post/will-gemma-4-actually-replace-claude-code

Worth reading if you're thinking about making this switch — or if you already tried and want to compare notes.

Gemma 3 couldn't have this conversation. Gemma 4 makes it real. Gemma 5 might actually answer it.

Have you wired Gemma 4 into a real dev workflow and tried to ship something? Not chat — actual coding work. Drop your experience in the comments or the forum thread. The honest data is in the field reports, not the leaderboard.

YouTube Mass Unsubscribe: My Brother Vibe Coded It in Class 11, I Refined It for Production

Bishwas Bhandari — Mon, 23 Feb 2026 05:28:31 +0000

My brother is 17 and in Class 11. He doesn't know what a REST endpoint is. He's never opened DevTools on purpose. Last month he built a Chrome extension that unsubscribes you from YouTube channels in bulk, and it worked.

And it worked. It actually worked. He wanted to nuke his entire subscription list. 300+ channels accumulated over years of binge-watching gaming walkthroughs, tech reviews, and random stuff the algorithm tricked him into subscribing to at 2am. His feed had become completely unusable. Every time he opened YouTube, it was wall-to-wall content from channels he didn't even remember subscribing to.

YouTube's solution? Click a channel. Click unsubscribe. Confirm. Go back. Scroll. Repeat. For 300 channels, that's close to a thousand clicks and an hour of mind-numbing repetition. He wasn't going to do that. So he decided to build something instead.

He opened Claude Code, described what he wanted in plain English, and started prompting his way through a Chrome extension from scratch. No tutorial. No roadmap. No "learn Chrome Extensions in 30 days" course. Just a kid with a problem and an AI editor willing to help him figure it out.

That's vibe coding. And I think it represents something genuinely new.

The DOM Clicking Approach

His first version required you to visit youtube.com/feed/channels, YouTube's subscription management page that lists every channel you're subscribed to. From there, the extension would scrape each channel element off the page, find the unsubscribe button, click it programmatically, confirm the modal, wait for the page to update, then move on to the next one. One channel at a time, clicking through the DOM like a very patient robot.

It was slow. It was fragile. YouTube changes their DOM structure between A/B tests and his selectors would break randomly. Sometimes the confirmation modal wouldn't appear fast enough and the script would click behind it. Sometimes YouTube's lazy loading wouldn't trigger and the extension would run out of channels to process halfway down the page.

But here's the thing. None of that mattered. He wasn't building a product. He was solving a problem. And the DOM clicking approach, janky as it was, successfully unsubscribed him from 200+ channels in about 40 minutes. Compare that to the 2+ hours of manual clicking he was facing.

I'm genuinely proud of him for this. A 17-year-old in Class 11 with no formal programming background shipped a functional Chrome extension in an afternoon. Not a to-do app. Not a calculator. A browser extension that scrapes and interacts with one of the most complex web applications on the planet. He figured out content scripts, manifest permissions, DOM traversal, async timing. Concepts that trip up junior developers. The AI helped him through each wall as he hit it. That's the part people miss when they dismiss vibe coding.

What Vibe Coding Actually Enables

The standard criticism goes something like this: vibe coding produces bad code, people don't understand what they're building, and the result is unmaintainable garbage.

All true. Also completely beside the point.

My brother's DOM-clicking extension was objectively bad code. Hardcoded selectors, no error handling, sequential awaits with arbitrary timeout values, zero separation of concerns. If you ran it through a code review it would get rejected before the reviewer finished their coffee.

But it shifted his relationship with software from consumer to creator. He went from "YouTube doesn't have this feature so I guess I'm stuck" to "YouTube doesn't have this feature so I'll build it myself." That mental shift is worth more than any CS fundamentals course.

Vibe coding didn't teach him to program. It taught him that programming is an option. There's a massive difference, and I think it's the most important thing happening in tech education right now.

The Refinement Gap

After watching his extension click through DOM elements for 40 minutes, I spent an evening rewriting it. Not because his approach was wrong, but because I knew there was a faster path.

YouTube's frontend talks to internal API endpoints for everything. Loading subscriptions, managing them, unsubscribing. The same endpoints the website hits when you manually click that unsubscribe button. Instead of simulating clicks on DOM elements, you can call these endpoints directly from the extension using the session token from the active YouTube tab.

The difference is night and day. The DOM approach: scroll, find element, click, wait for modal, confirm, wait for response, scroll again. The endpoint approach: fire an authenticated POST request. No clicking, no scrolling, no modals, no waiting for DOM elements to render.

Scanning 500+ subscriptions went from "scroll for five minutes while the page lazy-loads" to a single paginated API call that returns everything in seconds. Unsubscribing went from 40 minutes of automated clicking to a few minutes of sequential API requests with a configurable delay to avoid rate limits.

This is where the vibe coding conversation gets interesting. My brother built the proof of concept. I built the production version. Both were necessary. Without his janky DOM-clicking prototype, I wouldn't have spent an evening on this at all. The vibe-coded version validated the idea. The refined version made it reliable.

The 12x Cost Problem, Revisited

I've written before about how vibe coding carries hidden costs. Code that works but can't scale, technical debt that compounds, solutions that break under edge cases the AI never considered.

This extension is a perfect case study. The DOM version worked but had real problems. Channels with identical names confused the selector logic. Session expiry mid-process caused silent failures. YouTube's A/B testing meant the extension might work on Monday and break on Wednesday.

The endpoint version handles all of this cleanly. Channel IDs instead of display names. Auth token validation before each request. No dependency on DOM structure at all.

But here's where I've softened my stance: the cost problem matters for production software. For personal tools, prototypes, and "I just need this to work once" utilities? Vibe coding is genuinely magical. A 17-year-old solved a real problem in an afternoon. The code quality was irrelevant because the code's job was to run once and save him two hours of clicking.

The mistake isn't vibe coding. The mistake is not knowing when vibe coding is enough and when it needs a human with context to step in and refine.

What's In The Extension Now

The production version has the stuff you'd expect from a proper tool: one-click scanning of all subscriptions via API, a searchable list with avatars and subscriber counts, select/deselect all, CSV export for backup (critical since YouTube has no bulk re-subscribe), configurable delay between unsubscribes, live progress tracking per channel, and a stop button to pause mid-process.

It runs 100% locally. No data collection, no background processes, no server calls. The extension talks to YouTube through your authenticated tab and nothing else.

If your subscription list has gotten out of hand, it's free on the Chrome Web Store: YouTube Mass Unsubscribe

The Bigger Point

My brother doesn't call himself a developer. He probably never will. But he now understands, at a gut level, that the software on his screen isn't magic. It's just code that someone wrote, and with the right tools, he can write it too.

That's not a small thing. An entire generation is growing up with AI editors that translate intent into working software. Most of what they build will be rough. Some of it will be broken. Almost none of it will be production-quality.

And it won't matter, my brother in christ. Because the gap between "I have an idea" and "I have a working prototype" just collapsed from months to hours. The refinement can come later. From them as they learn, or from someone else who sees the potential in their janky, beautiful, vibe-coded proof of concept.

That's what happened here. A kid built something imperfect, and it became something real.

Built by Binay Bhandari and refined by Bishwas Bhandari at Webmatrices.

I tracked 20 Reddit posts across 14 subreddits. Here's what actually drove traffic.

Bishwas Bhandari — Sat, 31 Jan 2026 15:34:50 +0000

Last month I ran an experiment. Posted 20 times across 14 subreddits to see what actually works for driving traffic to technical content.

One post hit 226,000 views. Another got 0 upvotes and 44 hostile comments.

Same person. Same week. Here's what made the difference.

The numbers

From Reddit alone, in one week:

100,000+ views
15,595+ readers
1,700 hours of read time

Best post: 600 upvotes, 94.5% approval, 120 comments on r/webdev.

Worst post: 0 upvotes, 35% approval, 44 comments telling me I was wrong.

The one thing that mattered most

Third-person framing.

Framing	Example	Result
Third-person	"someone actually calculated..."	600 upvotes
First-person	"I made a contrarian analysis site"	1 upvote

Same content quality. 600x difference in results.

Reddit trusts discoveries. Reddit distrusts self-promotion.

"Found this breakdown" beats "I wrote this breakdown" every single time.

The post that hit 226K views

Title: "someone actually calculated the time cost of reviewing AI-generated PRs. the ratio is brutal"

Why it worked:

Third-person frame ("someone calculated" not "I calculated")
Specific number in title ("12x" ratio)
Lowercase, casual tone
Ended with a genuine question

The top comment got 156 upvotes: "We need an AI that automatically closes vibe coded PRs.. let them fight"

When your top comments are jokes agreeing with you, you've won.

The post that got destroyed

Title: "why would a company pay $1,500/year for SaaS when a dev can build it custom for $500?"

Posted to r/Entrepreneur. Business owners, not developers.

They didn't care about cost savings. They cared about reliability. I was speaking dev language to business people.

44 comments. All hostile. 0 upvotes.

Same article, different subreddits

This surprised me most.

Same "$599 Mac Mini" article:

Subreddit	Upvotes	Approval
r/ArtificialInteligence	412	81%
r/vibecoding	148	69%

264-point difference. 12% approval gap. Same content.

r/ArtificialInteligence wanted debate. r/vibecoding was tired of hype.

Subreddit culture matters more than content quality.

The AI-writing disaster

r/programming caught me.

Top comment, 120 upvotes: "God I hate reading all these LLM-written blog posts"

What they noticed:

Em dashes (—) everywhere
Short, choppy sentences
Repetition of the same points
Too much structure

If you use AI assistance, r/programming will find out. And they will make it the top comment.

The formula

After 20 posts, this is what consistently worked:

SPECIFIC NUMBER + THIRD-PERSON FRAME + GENUINE QUESTION = ENGAGEMENT

And this is what consistently failed:

FIRST-PERSON + PROMOTIONAL TONE + WRONG AUDIENCE = DEATH

The 97% approval trick

One post hit 97% approval. Highest ever.

What I did differently: gave free, detailed help in the comments.

Someone asked for feedback. Instead of saying "check my article," I spent 500 words auditing their site. Found broken code, inconsistent info, specific issues.

That comment got upvoted. Other people asked for help. I helped them too.

Free value in comments builds more trust than the post itself.

TL;DR

Third-person framing — "found this" beats "I made this"
Specific numbers — "12x ratio" beats "takes longer"
Know your subreddit — same content, wildly different results
Genuine questions — invites comments instead of judgment
Free value in comments — the real trust builder

I documented the whole thing with screenshots, the disasters, and the exact patterns that worked. If you want the full breakdown: The Subtle Art of Reddit Marketing

Or just take the formula above and test it yourself. The third-person framing alone changed everything for me.

I Analyzed 50+ SaaS Shutdowns. They All Made The Same Mistake.

Bishwas Bhandari — Fri, 30 Jan 2026 13:24:36 +0000

Spent the last few months reading shutdown posts. Not the advice posts. The actual failures.

The pattern was always the same. And it wasnt what I expected.

The Numbers That Broke Me

One founder got 2,600 free users in four months. Zero paying customers.

Another validated for two years. Talked to companies. They all said theyd pay. Zero paying customers.

20,000 users. 3,586 websites created. Shut down anyway.

These founders didnt lack effort. They didnt build bad products. They validated the wrong thing.

Stated Preference vs Revealed Preference

Theres a concept in behavioral economics that explains everything.

Stated preference is what people say theyll do. Revealed preference is what they actually do.

When you ask "would you pay for this?" youre asking someone to simulate a future version of themselves making a purchasing decision. That simulation is wrong almost every time.

One founder ran 300 beta tests. Video calls. Excited users. Tons of feedback. Launch day came. Nobody converted.

His reflection was brutal. Interest does not equal willingness to pay.

The Vanity Metrics Factory

One founder described their free trial as a "vanity metrics factory." Free trials attract tire kickers, students doing research, and competitors poking around. The dashboard shows growth. The bank account shows nothing.

This founder killed their free trial. Everyone told them it was suicide. Signups dropped 70%.

Revenue went up 40%.

The free trial was filtering IN the wrong people. Removing it filtered them OUT. Fewer users. More customers.

The Question That Changes Everything

After reading all these shutdown posts I noticed one question that separated winners from losers.

"What are you doing about this problem right now?"

Listen to the answer.

"Nothing, its fine." Not a real problem.

"We complain about it sometimes." Awareness without action.

"We have a spreadsheet that kind of works." Workaround. Good sign.

"We hired a contractor to handle it manually." Spending money. Great sign.

"We use [competitor] but it sucks." Active buyer. Best sign.

The goal isnt finding people who acknowledge the problem. Its finding people already spending time or money to solve it imperfectly. Those people will pay you. Everyone else is being polite.

The $1 Filter

The only real validation is a transaction. Not "I would pay." Not "sounds interesting." Money.

One founder added a $1 paywall to their free trial. Conversion rate went from 3% to 41%.

The $1 wasnt about revenue. It was about filtering. Anyone willing to pay $1 is categorically different from someone who isnt.

This feels wrong to most developers. We want to build first, charge later. But products dont speak. Customers do. And they speak loudest with their wallets.

The Pain Hierarchy

Not all problems are equal. Knowing which ones people will actually pay to solve before you build is everything.

Are they aware of the problem? Are they actively searching for solutions? Do they have existing workarounds? Are they already spending money on something? Is there built in urgency? Who controls the budget?

Most founders validate the first two levels and call it done. The money is in levels three through six.

Vitamins vs Painkillers

Most failed SaaS products are vitamins marketed as painkillers.

The test is simple. If your product disappeared tomorrow, would customers notice within 24 hours? Would they actively seek a replacement? Would they pay more to get it back?

If the answer is no, you built a vitamin.

What Actually Works

The pattern of successful founders was clear.

They charged early, often before the product was ready. They filtered aggressively, losing tire kickers on purpose. They found people with workarounds, not just people with problems. They talked to budget owners, not just pain experiencers. They built distribution before product.

They treated signups as vanity. Only revenue counted.

The Uncomfortable Truth

If youre reading this and feeling uncomfortable, good.

The founders who posted these shutdown stories all had skills to build great products. They all worked hard. They all "validated."

They all failed because they validated the wrong thing.

I wrote a full playbook on this. Analyzed 50+ real shutdowns, extracted the patterns, built frameworks you can actually use.

Chapter one is free. Covers the validation lie with more data and case studies.

Chapters two through four cover the exact playbooks for filtering buyers, identifying real pain, and building distribution before product.

The SaaS Validation Playbook

Reddit to LLM.txt

Bishwas Bhandari — Wed, 21 Jan 2026 14:00:42 +0000

You found it. The perfect Reddit thread. 300+ comments of exactly the conversation you need for your AI project.

You start copy-pasting. Five minutes in you realize you missed half the nested replies. You go back. You're trying to figure out which comment was responding to which. An hour later you have a document full of text with no structure and no idea who said what or when.

this is the problem nobody talks about.

Reddit is the best training data on the internet. Real conversations with actual nuance. But every way to extract it is broken. Manual copy-paste doesn't scale. Scrapers require a CS degree to configure. The API means writing code and dealing with rate limits. And even when you get the text out, it's just a wall of words. No hierarchy. Your model can't learn conversation structure from that.

One click and you get a clean markdown file. The full post. Every comment including the nested ones. Proper hierarchy so your LLM can actually understand who was replying to whom. All the metadata. When you feed this to GPT or Claude or your fine-tuned model, it can parse the conversation structure instead of just seeing words in sequence.

Everything runs in your browser. The extension reads Reddit's public API—the same data you'd see if you added .json to any URL. Nothing goes through our servers. Your data stays yours.

Built for AI researchers creating training datasets. Developers fine-tuning on specific communities. Anyone who's ever thought "I wish I could just download this entire thread" and then spent an hour copy-pasting.

this is exclusive to webmatrices members.

/reddit-to-llm

"taste scales. slop doesn't." — best breakdown i've seen on AI coding economics

Bishwas Bhandari — Mon, 19 Jan 2026 07:56:37 +0000

25-35% of new code in large organizations is now AI-assisted.
Everyone's shipping faster.
But someone has to review that code. Maintain it. Debug it at 3am.
Those people are burning out.

The Math
I tracked a typical AI-generated pull request:

Contributor time: 7 minutes
Maintainer time: 85 minutes
Ratio: 12x

And when you request changes? They feed your feedback to the AI and regenerate the whole thing. You're reviewing from scratch.
One maintainer told me he's stopped reviewing PRs entirely: "I can't tell anymore which ones are real contributions and which are someone farming GitHub activity for their LinkedIn."

The Security Problem
Radware's threat intelligence team analyzed 500,000 code samples and found "synthetic vulnerabilities" — security flaws unique to AI-generated code.
Key findings:

AI errors are disproportionately high-severity (injection, auth bypass)
"Hallucinated abstractions" — AI invents fake helper functions that look professional but are broken
"Slopsquatting" — attackers register hallucinated package names with malicious payloads

What This Means for Hiring
New interview question: "Walk me through a bug you personally debugged in this code."
If they can't explain trade-offs, they didn't write it.

The developers who thrive won't be the ones who generate the most code.
They'll be the ones who can tell the difference between code that compiles and code that belongs.
Taste scales. Slop doesn't.

Full breakdown in comments 👇

Developers killed Tailwind. Not AI.

Bishwas Bhandari — Wed, 14 Jan 2026 05:28:39 +0000

We just don't want to admit it.

AI is the easy scapegoat.
"LLMs bypass the docs."
"Cursor generates Tailwind without asking."
"Nobody visits the website anymore."
Sure. All true.
But when was the last time you paid for something you could get for free?
Exactly.

Tailwind has 75 million downloads a month.
They just fired 75% of their team.
→ npm downloads: All-time high
→ Revenue: Down 80%
→ Runway: 6 months left
Most popular CSS framework in history.
Nearly bankrupt.
Popularity is not a business model.

Shadcn gave away the same components for free.
Junior devs copy-pasted from CodePen for years.
The "premium templates" moat was made of paper.
AI didn't kill the business.
AI just automated what we were already doing for free.

And here's what really gets me:
$1M+/year in sponsorships.
Still struggling.
Blender — the entire 3D software industry's backbone — runs on $3M/year.
Tailwind needed a third of that to maintain... shorter class names?
Something doesn't add up.

They were hiring engineers at $275k.
For a CSS library.
That's not a sustainability problem.
That's a spending problem.

Now Google and Vercel suddenly show up with sponsorships.
Where were they 6 months ago when the runway was burning?
They didn't show up to save open source.
They showed up for the PR headline.

The math is brutal:
Usage ≠ Revenue.
Downloads ≠ Dollars.
npm installs ≠ Survival.
You can power half the internet and still go broke.

Stack Overflow is dying.
Tailwind almost died.
Dev blogs are ghost towns.
Any business that needs you to visit a website to make money?
Already dead. AI just signed the death certificate.

I use Tailwind every day.
I let AI write half of it.
I've never paid Tailwind a single rupee.
Neither have you.

So let's stop blaming AI.
The mirror is right there.

Who really killed Tailwind — the robots, or the culture that wants everything free?

AI generated code is just slop!

Bishwas Bhandari — Tue, 11 Nov 2025 11:34:41 +0000

SHlT, I am writing this...

AI coding is so fking frustrating. There's literally no life in it.
AI can't replace a human coder. Can't even replace a junior dev.
Yeah yeah, I know - some dev sits there instructing the AI to write code and it kinda works. But here's what nobody wants to talk about:
Who's taking responsibility when shit breaks? Who's guaranteeing that code actually works? Not the AI. You are.

The AI-generated code? Pure slop. And we all know it.
But here's the worst part - you get so used to this garbage that you don't even understand your own fking code anymore. I hate AI, but I'm accustomed to it. We all are.

That's the real tragedy. We're all becoming prompt monkeys who can't even read what we just "wrote."

I rewrote Mermaid integration for Svelte 5 - Turns out everyone's been doing it wrong

Bishwas Bhandari — Sun, 31 Aug 2025 16:02:21 +0000

Two weeks ago I was building docs for a client project and needed some flowcharts. Simple, right? Wrong.

Spent 3 hours fighting with existing Mermaid solutions. Configs breaking, themes not switching properly, SSR throwing fits. At one point I actually considered just drawing the diagrams in Figma and embedding images like some kind of barbarian.

That's when it hit me - we've all been treating Mermaid like it's 2019. Import a library, fight with initialization, pray it works with your build system. But this is Svelte 5. We have runes now. Why are we still coding like peasants?

So I built @friendofsvelte/mermaid - the way diagrams should work in 2025.

<script>
  import { Mermaid } from '@friendofsvelte/mermaid';

  const architecture = `graph TD
    A[Old way: Fight configs] --> B[Waste 3 hours]
    B --> C[Settle for broken solution]

    D[New way: Just works] --> E[Ship features]
    E --> F[Happy developers]`;
</script>

<Mermaid string={architecture} />

Here's what I learned building this

Everyone's overthinking Mermaid integration. The existing solutions try to handle every possible edge case, every framework, every version. Result? Bloated APIs that feel foreign in Svelte.

Runes changed everything. The internal state management is so clean now. What used to take 50 lines of reactive statements is now 5 lines of $state and $derived.

Theming was the real pain point. Most solutions make you fight CSS variables or override styles. This component just accepts a theme prop and handles the rest.

What this actually does

Themes that switch instantly - Dark mode, custom colors, no flicker
Proper TypeScript - Full type safety, intelligent completion
All diagram types - Flowcharts, sequence, Gantt, user journeys, the works
Error handling that helps - Actually tells you what's wrong with your diagram syntax
Responsive by default - Works on phones without you thinking about it

The controversial part

Most Mermaid integrations are solving the wrong problem. They focus on compatibility and features instead of developer experience. But here's the thing - if your diagram component feels like work to use, you're less likely to document things properly.

Good documentation tools should disappear. You should think about your content, not your tooling.

Real talk: Why this matters

I've seen too many projects with terrible docs because the diagram tooling was a nightmare. Teams skip flowcharts, avoid sequence diagrams, and end up with docs that nobody understands.

When adding diagrams is as easy as writing markdown, teams actually document things. And that makes better software.

Try it yourself

Site: https://mermaid-cjv.pages.dev/
Install: npm install @friendofsvelte/mermaid

Svelte 5 only - because backward compatibility is the enemy of progress.

What I'm building next

This is part of a bigger documentation toolkit I'm working on. Thinking about components for API docs, interactive code examples, maybe even live demo embedding.

The goal? Make documentation so smooth that teams actually want to write it.

What kind of diagrams are you adding to your projects? Anyone else frustrated with how complicated this stuff has become?

Forem: Bishwas Bhandari

I built a LinkedIn MCP server for Claude in a weekend. Here's the Python + Playwright pattern.

TL;DR

The naïve approach (and why it breaks)

The architecture that worked

The three tools, and the prompts that actually work

linkedin_search (the workhorse)

linkedin_feed (for taking the temperature)

linkedin_post_comments (the underrated one)

How SuperMCP keeps accounts under the radar

How this stacks up against the alternatives

Installing it

Why I bundled this with Reddit, Twitter, and the rest

FAQ

I built a free backlink suggester for indie founders. Here is what 4 weeks of audits taught me.

how it actually works

the four patterns I keep seeing

what surprised me

what is on the roadmap

the meta-point

I Stopped Fighting the Reddit API, So I Built SuperMCP to Read It for Me

What It Actually Does

The Trick: Your Chrome Login Session

Setup: 3 Commands

What This Looks Like in Practice

The 13 Tools

Why Not Just Use the APIs Directly?

FAQ

Gemma4 vs Claude Code: I Tried the Switch. Here's What Broke First.

What Made This Test Worth Running

The First 4 Hours Are Genuinely Impressive

Where It Broke

The Tool Calling Problem Is Worse Than the Benchmarks Suggest

There's Hidden Performance That Hasn't Shipped Yet

What Claude Code Actually Does That's Hard to Replace

So What Actually Happens to the Subscription Economy?

The Conversation Developers Are Actually Having

YouTube Mass Unsubscribe: My Brother Vibe Coded It in Class 11, I Refined It for Production

The DOM Clicking Approach

What Vibe Coding Actually Enables

The Refinement Gap

The 12x Cost Problem, Revisited

What's In The Extension Now

The Bigger Point

I tracked 20 Reddit posts across 14 subreddits. Here's what actually drove traffic.

The numbers

The one thing that mattered most

The post that hit 226K views

The post that got destroyed

Same article, different subreddits

The AI-writing disaster

The formula

The 97% approval trick

TL;DR

I Analyzed 50+ SaaS Shutdowns. They All Made The Same Mistake.

The Numbers That Broke Me

Stated Preference vs Revealed Preference

The Vanity Metrics Factory

The Question That Changes Everything

The $1 Filter

The Pain Hierarchy

Vitamins vs Painkillers

What Actually Works

The Uncomfortable Truth

Reddit to LLM.txt

"taste scales. slop doesn't." — best breakdown i've seen on AI coding economics

Developers killed Tailwind. Not AI.

AI generated code is just slop!

I rewrote Mermaid integration for Svelte 5 - Turns out everyone's been doing it wrong

Here's what I learned building this

What this actually does

The controversial part

Real talk: Why this matters

Try it yourself

What I'm building next

`linkedin_search` (the workhorse)

`linkedin_feed` (for taking the temperature)

`linkedin_post_comments` (the underrated one)