Six Products. Same Form Factor. Tap Is the Substrate.

May 1, 2026 · Leon Ting · 5 min read

In the last six months, six independent indie products converged on the same form factor:

A Chrome extension that reads what the user can already see when they're logged in — but the host site never exposes via API.

Not five products with different architectures solving similar problems. Six products with the same architecture solving completely different problems. When that pattern surfaces, the architecture is the product.

We've been building the substrate underneath it for 18 months.

The pattern

Five of the six are real products people pay for. One we just discovered the niche is already crowded with free OSS in the same week we started planning. That's a separate lesson — planning velocity has to match supply-side velocity in this category, or someone ships your wedge while you draft your spec — but it doesn't change the structural point.

The five that exist all share the same anatomy:

[user's logged-in Chrome session]
        │
        ▼
[Chrome extension]    ← reads what the page already has
        │
        ▼
[server-side processing or no server at all]
        │
        ▼
[badge / overlay / report injected back into the page]

Why the form factor wins

The structural reason this pattern is showing up six times in six months:

1. Cookies are the only credential that works. The host site won't issue an API key for what you want. The host site will rate-limit any other identity that asks. The user's own session — the cookies their browser already has — is the unique credential the host can't refuse.
2. No server-side cloud bridge to your provider. Every cloud-based browser SDK (Stagehand+Browserbase, Apify, Vercel-Agent-Browser) needs the user to ship credentials to the cloud, where they're a single breach away from the breach surface of the entire provider. The Chrome-extension form factor never crosses that trust boundary.
3. Distribution is local. The user installs an extension. They run it on the page they're already on. There is no SaaS dashboard to sign into, no API key to provision, no credentials to share. The output is visible inside the host site's own UI.

This is a pattern. The pattern keeps recurring because the architecture solves a real problem the cloud-first SDKs structurally can't.

Where Tap fits

Each of the six products above needs the same primitives:

• A Chrome extension runtime that survives the host site's anti-bot measures (postcopilot vs Threads' anti-export script)
• A way to express extraction logic as data, not code, so the same logic survives DOM reshuffles
• A way to test that extraction in CI without the host site changing
• A way to dispatch authenticated requests from the user's session — not yours, not a cloud's

We've been building that. The CLI is tap. The extension is at LeonTing1010/tap. The extension primitives are an 8-op core + 17 built-in pipe ops. The plan format is W3C Annotation. The runtime contract has just been extended (ADR 2026-05-01-op-fetch-page-session) so authenticated requests carry the user's logged-in cookies and never leave their machine.

PostGhost is built on Tap. Tikomate is being built on Tap. The two new W18 entrants — postcopilot and superpower-for-gemini — don't know about Tap yet. They're our distribution opportunity.

What we're not saying

We're not saying every Chrome extension wins. We're not saying we have proof that all six form-factor products will succeed financially. The dev-AI-tool spend tracker is already crowded for indie monetization because free OSS competitors got there first.

We're saying: when six different solo founders converge on the same architectural pattern in the same six-month window, the pattern itself is a structural fact. If you're building the seventh, the question isn't "should this exist?" — it's "do I want to build the substrate alone, or join the substrate that's already there?"

If you're building the substrate, talk to us.

brew install LeonTing1010/tap/taprun
tap mcp connect

Drafted from solo-monitor stream W18. Two of the six (postcopilot, superpower-for-gemini) discovered this week as independent external validations of a form factor we'd been organizing internally for months. Sources: PostGhost shipping repo, IH product pages for postcopilot and superpower-for-gemini, internal planning docs.