Why I’m Building Two Products for the Same Problem

People keep trying to squash this into one sentence and one product.

I get why. It sounds cleaner.

"It's an extension security platform."

Sure. That's true in the same way that saying a firewall is "a networking tool" is true. Not wrong, just too small to be useful.

What I'm actually building is two products aimed at the same ugly problem.

RiskyPlugins is one.

PrivateStores is the other.

They should work together closely. They should not be the same thing.

The problem is simple

People install third-party code with broad permissions and barely think about it.

That code lives in browsers. It lives in VS Code. It lives in OpenVSX forks. It lives in MCP servers. It lives in agent skills. It lives in all the little "helpful" things that quietly get access to files, tokens, terminals, cloud APIs, browser sessions, and internal data.

Most of the time nobody really knows:

• what changed
• who published it
• whether the publisher is still trustworthy
• what the code can actually touch
• whether the latest update is sane

That is the mess.

RiskyPlugins exists because trust needs an intelligence layer

RiskyPlugins is the part that answers the uncomfortable questions before install time.

It indexes public ecosystems, pulls artifacts down, scans them, scores them, tracks changes, clusters developers, and turns the whole thing into something queryable.

That is why the public website exists.

That is why the API exists.

That is why I built the hosted MCP server.

I want the product to be usable by humans, sure. But I also want it usable by agents and automation. If Claude Code, Codex, or some internal workflow is about to deal with a plugin or MCP server, I want it to be able to ask the same questions I would ask.

RiskyPlugins is the intelligence layer.

It tells you what looks dangerous, what looks weird, and what deserves more attention.

But intelligence alone is not enough

This is where most security products stop too early.

They'll happily tell you that something looks risky, then leave you holding the bag.

Cool. Now what?

Am I blocking it?
Approving it?
Delaying updates?
Mirroring a known-good version?
Forcing teams through review?
Pinning versions?
Keeping an audit trail?

That is not an intelligence problem anymore. That's a control problem.

And that's why PrivateStores exists.

PrivateStores is the control plane

PrivateStores is for the moment after you already know public marketplaces are not enough.

It gives organizations a private place to:

• approve extensions
• reject them
• quarantine them
• delay updates
• mirror known-good versions
• control catalog visibility
• audit what was allowed and why

That is a completely different kind of value.

RiskyPlugins tells you whether something smells bad.

PrivateStores decides whether it gets through the front door.

Those are connected jobs. They are not the same job.

Why I don't want to mash them together

Because that is how products get bloated and stupid.

If I merge everything into one giant blob too early, I end up with a thing that is harder to explain, harder to sell, harder to build, and harder to operate.

RiskyPlugins needs to move fast on:

• analysis quality
• scoring
• marketplace coverage
• APIs
• hosted MCP
• AI-era plugin ecosystems

PrivateStores needs to move fast on:

• tenant onboarding
• policy
• approvals
• mirroring
• RBAC
• auditability
• client compatibility

Different problems. Different motions. Different buyer pressure.

The clean split is:

RiskyPlugins is the intelligence plane.

PrivateStores is the enforcement plane.

That's the architecture and the business model.

This is also the business logic

People love talking about "platforms" because it sounds grand. I don't care about sounding grand. I care about where the money actually comes from.

RiskyPlugins makes sense as:

• public discovery
• scorecards
• API access
• hosted MCP
• team workflows
• intelligence subscriptions

PrivateStores makes sense as:

• enterprise control
• private catalogs
• approval workflows
• rollout policy
• custom deployments
• audit and governance

One sells insight.

The other sells control.

Enterprise buyers usually pay harder for control than insight, which is exactly why PrivateStores matters.

The part that gets more interesting now

This used to be mostly about browser and IDE extensions.

It isn't anymore.

Now the same problem is showing up in:

• MCP servers
• agent plugins
• agent skills
• subagents
• remote tool integrations

The shape changes a bit, but the trust problem is the same.

Unknown code. Broad permissions. Weak review. Fast distribution. Easy update path.

Which means the same two-product model still works:

• RiskyPlugins figures out what looks dangerous
• PrivateStores controls what gets allowed into an environment

That applies just as well to AI tooling as it does to browser extensions.

So why am I building this?

Because I think the market is still pretending this is a niche annoyance when it's actually a supply chain layer nobody has taken seriously enough.

Package managers got their tooling.

Containers got their tooling.

Extensions and agent plugins mostly didn't.

I'm building the thing I think should already exist:

a trust layer for third-party code, and a control layer for organizations that are sick of hoping public marketplaces behave themselves.

That's RiskyPlugins and PrivateStores.

Two products.

Same problem.

Different jobs.