How Risky Is Buying a Plugin Business?

I recently came across a SaaS business built as a Google Workspace add-on. When I first came across the listing, the fact that it was a Google Workspace add-on was one of the things I liked most about it. The concept was simple, useful, and easy to understand. It plugged directly into a platform people already used, which meant the product did not have to convince customers to completely change their workflow. It had recurring revenue, low operating costs, and built-in access to a large marketplace. At first glance, it looked like the kind of small software business that could be both practical and scalable.

But once I started evaluating it seriously, I had to look beyond the product itself. Buying an add-on also means buying into the rules, APIs, permissions, and risks of the platform it depends on. The product was a Google Workspace add-on. Customers discovered it through Google’s marketplace, signed in through Google’s systems, and depended on Google’s APIs for the software to function.

I was not looking at a completely independent SaaS. I was looking at a business that existed inside someone else’s ecosystem. If I wanted to understand the opportunity properly, I also had to understand the rules, permissions, APIs, and risks that came with that platform.

When you evaluate a traditional SaaS, you usually focus on:

When you evaluate a plugin, extension, add-on, or marketplace app, there is another layer to the deal. You are not only evaluating the software. You also have to evaluate the platform underneath it. The business may belong to the seller, but the ground underneath it belongs to someone else. It’s like paying rent in a house you do not own. You can build something valuable inside it, improve it, and make money from it, but the landlord still controls the property and can change the rules.

That creates a completely different set of diligence questions. Can the marketplace listing transfer to a new owner? Can the developer account, OAuth credentials, and API access move with the business? Could a policy change limit what the product is allowed to do? Could an API update force an expensive redevelopment? How much customer growth depends on marketplace rankings? And most importantly, would the software still have a business if the platform listing disappeared?

Those questions may not show up on the profit-and-loss statement, but they can completely change the risk of the acquisition.

One of the biggest advantages of building on a large platform is distribution. Instead of convincing people to discover an unknown website, the business can appear where customers are already searching. That might be:

That distribution can be extremely valuable. A small developer may reach thousands of users without building a huge marketing team or spending heavily on advertising. The platform provides trust, discovery, installation, and sometimes even billing. It can make a tiny software business look much larger than it really is.

But that advantage comes with a tradeoff. If most new customers come from one marketplace, the platform is no longer just a marketing channel. It becomes part of the business model. If rankings fall, installations may fall. If reviews decline, conversion may fall. If the listing is suspended, customer acquisition may stop almost immediately. A company may appear to have strong organic growth when most of that growth is actually being rented from a marketplace algorithm. That is still valuable. It is just not fully controlled by the business.

This is not unique to Google.

A Shopify app depends on Shopify’s APIs, billing rules, approvals, rankings, and policies. A platform change can create development work, reduce installations, or even lead to suspension.

WordPress offers huge distribution, but updates to WordPress, PHP, or another plugin can break compatibility overnight. Nothing ruins a quiet weekend faster than thousands of sites suddenly throwing errors.

Chrome extensions depend on browser permissions, store approval, and Google’s extension rules. A major standards change can force a product that worked for years to be partially rewritten.

These apps rely on external APIs, permissions, security requirements, and review processes. The product may be healthy while still facing risks the owner cannot control.

At first, I was focused on the usual questions like revenue, customers, and churn. But that’s not enough. When evaluating a plugin business, I would focus on four main questions:

Confirm that the marketplace listing, developer account, API access, and other platform accounts can move to the buyer.

Ask whether it has ever been warned, suspended, rejected, or affected by a policy change.

Understand how much growth depends on marketplace rankings compared with the company’s own website, email list, referrals, or direct traffic.

Find out whether the product could keep operating if an API changed, rankings declined, or the marketplace listing disappeared.

These questions are simple, but they cover most of the platform risk a buyer needs to understand. A business might have stable recurring revenue today while still being one policy update away from a very expensive problem.

It would be easy to conclude that plugin businesses are simply too risky to buy. I do not think that is true. Large platforms can reduce customer acquisition costs, simplify onboarding, build trust, and put the product in front of users who already need it. In some cases, a marketplace-dependent SaaS may be easier to grow than a standalone product that has to create demand from scratch.

The real question is not whether platform dependence exists. It is whether the purchase price reflects it. A business with direct traffic, an email list, recognizable branding, and several customer acquisition channels is less exposed than one that depends almost entirely on a single marketplace ranking.

A buyer should also look for ways to reduce that dependence after closing. That could mean:

You may never eliminate platform risk completely. The goal is simply to avoid being completely helpless if the landlord wakes up one morning and tells you to kick rocks.

Platform risk should be treated like any other acquisition risk. If most customers come from one marketplace, that should affect the valuation. If ownership transfer is uncertain, that should affect the deal structure. And if one API change could require a major rebuild, that future cost should be considered before closing.

There Are Several Ways To Price the Risk In. You could respond with:

The platform does not automatically make the business unattractive. It just means the buyer should not value it like a completely independent SaaS with full control over its distribution.

During this evaluation, I realized I was not just evaluating software. I was evaluating an ecosystem. The product had customers, revenue, and strong margins. But it also depended on another company’s marketplace, authentication system, APIs, policies, and search rankings. That dependency did not make it a bad business. It made it a different type of business. Some companies own their distribution. Others rent it.

Renting distribution can be extremely profitable, especially when the landlord is sending you customers. But before buying a plugin, extension, or marketplace app, make sure you understand the lease. Because even if the business belongs to you, The rules never will.