From WordPress plugin to SaaS product

What separates a plugin from a SaaS product?

A plugin is code that is downloaded once and runs inside a site. A SaaS product is a service you operate, update continuously and charge for as long as it delivers value. The difference is rarely the code. It is the structure: who pays, for what, who ships updates and how support works.

In the classic plugin model revenue arrives once, while support, compatibility fixes and new WordPress releases demand work every month. That mismatch is the usual reason good plugins go unmaintained after a few years. A subscription aligns revenue with the ongoing cost of keeping the product alive.

Not every plugin should become SaaS. A tool that runs entirely inside the site with no external processing rarely justifies a subscription. The move makes most sense when the heavy work happens outside the site: AI calls, image processing, reporting, sync or backups.

What should your pricing be tied to?

Users pay for an outcome, not a feature list. The pricing metric should grow with that outcome. Pick the wrong one and either small customers leave or large customers get a lot for very little.

Metric	Fits plugins that	Watch out for
Number of sites	Agencies deploy across many clients	Single-site SMEs need an entry tier
Volume (requests, documents, images)	Do work on an external service	Users must see their usage in the dashboard
AI calls or tokens	Use a language model	Model costs move, so leave margin
Seats	Teams use together	Map seats to WordPress user roles
Feature tier	Have advanced settings	The free tier must still be useful alone

If you sell into Türkiye as well as the EU, decide early whether you show Turkish lira prices locally and euro or dollar prices elsewhere. Two price lists are often the most honest answer.

What do the WordPress.org guidelines allow?

If your free edition is listed in the WordPress.org directory, your business model has to fit the directory’s rules. The Detailed Plugin Guidelines are explicit.

Allowed	Not allowed
Acting as the interface to an external service that does real work	Locked code in the free plugin that opens only after payment
Selling a separate Pro plugin	Tracking users without their consent
A restrained upgrade notice in the admin	Delivering updates from a server other than WordPress.org
Linking the service’s terms in the readme	A service that only checks a licence and does nothing else

In practice you choose between two routes. A free plugin plus a separate paid plugin, or a free plugin that connects to your service where the paid work runs. The second route is closer to real SaaS and harder to copy.

How should licensing and billing work?

Emailing licence keys by hand and chasing renewals works for the first ten customers. After that it becomes a source of errors. You need an automated layer.

• Payments and subscriptions: Stripe Billing, Paddle, Lemon Squeezy or Freemius. Check each provider’s supported countries for the entity you sell from.
• Licence validation: the plugin sends a short request to your service through the WordPress REST API or your own endpoint, and the key is bound to the site’s domain.
• Invoicing: if you sell from a Turkish entity, domestic sales require e-invoices (e-Fatura or e-Arşiv). A small automation that connects the payment provider to your accounting system removes month-end manual entry.
• Failed payments: send an automatic email and allow a short grace period. Switching the licence off instantly loses customers you could have kept.

How do you keep support from eating the margin?

Support is where subscription economics erode fastest. When the same questions arrive every day, the team stops building. A three-layer setup works.

First, searchable and current documentation. Second, an AI assistant that knows that documentation and your site content. Our own WordPress plugin, Promptor, is built on this idea: it brings an assistant that answers from the site’s content into the WordPress dashboard. Third, a flow that tags incoming tickets automatically and separates product bugs from missing documentation.

The assistant must hand questions it cannot answer to a person. A made-up answer costs more than an unanswered one.

Which measurements actually matter?

Without measurement the roadmap becomes guesswork. But in the WordPress ecosystem consent is not negotiable. The directory guidelines forbid tracking users without consent, and the privacy chapter of the Plugin Handbook explains how plugins should handle personal data and hook into WordPress’s export and erasure tools. For EU users, GDPR applies on top of that.

With opt-in, anonymous event data you can answer four questions:

• How many users actually used the core function after installing?
• Which features are never opened?
• Where do users hit errors?
• Which usage pattern precedes an upgrade?

Those four answers are enough to rework the pricing page and the setup wizard. More data is usually noise.

How we approach it at Corrplus

We had to answer most of these questions for our own products. Promptor is live on WordPress.org, and tools such as ContentCheckR, FAQPilot and ImagentElli are in development. In client projects we first decide together which part of the plugin can move into a service. Then we write down the pricing metric, the licensing and billing flow and the support layer before building in short cycles. See our WordPress and web platform development service, or look at Promptor to see the approach in a shipped product.