Skool’s True Cost vs Self-Hosted WordPress as Your Community Grows

Skool looks simple on the pricing page. One plan, unlimited members, no hidden tiers, no per-seat charges, no usage limits. That simplicity is part of the pitch.

But the flat subscription is not what you actually pay to run a Skool community at scale. Once you account for payment processing fees on every subscription you sell, features Skool does not offer that you have to build or buy elsewhere, and the long-term cost of not owning your data or your member relationships, the real picture looks very different from a single tidy number on a pricing page.

Updated September 2026.

This post runs the structural argument at three realistic community sizes: 500, 1,000, and 5,000 paying members. It compares Skool against a self-hosted WordPress stack built on BuddyPress and Jetonomy, and it walks through a framework you can apply to your own numbers rather than a single fixed price comparison that goes stale the moment either platform changes its rates.

What Skool Actually Charges

Skool has one paid plan, billed monthly or at a discount annually. That covers the platform itself. But running a paid community on Skool means you are also paying standard card-processing fees on every transaction your members make, the same percentage-plus-fixed-fee structure that applies to nearly every online payment anywhere.

Here is the part the flat-pricing pitch does not emphasize: that processing cut is not a platform fee you can shop around or negotiate away easily at small scale, and it applies on top of the subscription, not instead of it. If you have a meaningful number of members renewing monthly, the processing cost alone can exceed the platform subscription within the first few months, and it keeps growing in direct proportion to your revenue for as long as you run the community.

There is also what I call the ownership cost. On Skool, your member data lives in Skool’s database. Your community lives on Skool’s infrastructure. If Skool changes its terms, raises prices, or bans your account, you have limited recourse. Trustpilot reviews document exactly this problem: accounts banned with no explanation, communities deleted overnight, support unresponsive for weeks.

The Skool Trustpilot page currently sits at 1.9 out of 5. The recurring complaint is not about the product features. It is about what happens when something goes wrong. One review from a creator with hundreds of paying members describes losing the community with no warning and no path to recover member data.

The Shape of the Cost Curve

The structural point worth internalizing is this: the subscription is a fixed line item that barely moves as you grow. The processing cut is not. It scales linearly with your revenue, which means it scales linearly with your success. The better your community does, the larger that cut becomes in absolute terms, forever, with no ceiling and no volume discount available to you directly through the platform.

The Self-Hosted Stack: What It Costs to Run Your Own

A self-hosted community on WordPress is not free to run. There are hosting costs, plugin costs, and initial setup costs. What it is not is a recurring subscription you cannot cancel without losing everything, and its cost structure behaves fundamentally differently as you grow.

Here is the realistic stack for a community site that matches Skool’s feature set and exceeds it in several areas, along with how each component’s cost actually behaves as your member count grows.

Stack Components and How Their Cost Behaves

Component	What It Covers	Cost Behavior as You Scale
WordPress hosting	2 vCPU, 4GB RAM, scalable tiers	Fixed per tier; jumps in occasional steps as you upgrade capacity, not continuously per member
BuddyPress	Member profiles, activity feeds, groups	No license cost at any scale
Jetonomy	Forum, Q&A, course discussions, support threads	Flat annual license, independent of member count
WooCommerce	Payments, subscriptions, checkout	No license cost at any scale
WooCommerce Subscriptions	Recurring billing, dunning, trials	Flat annual license, independent of member count
Card processing fees	Payment processing	Same percentage-plus-fixed-fee structure as Skool, since the rate is set by the processor, not the platform
CDN for media delivery	Fast global delivery for media	Scales with bandwidth used, far more slowly than member count grows
Transactional email	Community and billing emails	Scales with volume in small increments
SSL, backups, monitoring	Security and uptime	Flat regardless of member count

Notice the pattern: almost every line item on the self-hosted side is either flat, or it grows in large occasional steps (upgrading a hosting tier) rather than continuously with every new member. The one line item that scales the same way it does on Skool is the card processing fee, because that rate is set by the processor, not by the platform you build on. That is the honest, apples-to-apples comparison: both sides pay the same processing structure, but only one side also pays a platform that takes an additional cut on top of it.

There is one more line item the self-hosted route requires that Skool does not: setup and occasional development. A clean initial build takes real time and either your own hours or a developer’s, and ongoing maintenance requires a modest recurring time or budget commitment for plugin updates, performance tuning, and small customizations. This is real and should not be waved away. It is also a cost that does not scale with your member count the way a percentage-of-revenue cut does. A 5,000-member community does not need five times the maintenance work that a 1,000-member community needs; it mostly needs the same maintenance, running on a larger hosting tier.

Why the Comparison Reverses Over Time

The first-year comparison can favor Skool at small member counts, especially once you count the setup effort for the self-hosted option as a cost. The multi-year picture reverses that almost entirely, and the reason is structural, not incidental.

Skool’s total cost is dominated by a fee that scales with your revenue, compounding every renewal, forever. The self-hosted stack’s total cost is dominated by a build cost you pay once and a maintenance cost that grows only in large, infrequent steps. Run that forward three years and the gap does not just persist, it widens, because one side’s cost curve is roughly flat and the other side’s cost curve tracks your growth directly.

At 500 paying members, the crossover point where self-hosting becomes cheaper typically arrives within the first year. At 1,000 members, it arrives faster, because the processing cut Skool takes on top of its subscription is now applied to twice the revenue. At 5,000 members, the platform’s cut has grown into a genuinely large ongoing cost, while the self-hosted stack’s hosting bill has grown only modestly, perhaps one or two tier upgrades higher than where it started. The self-hosted total at that scale remains a small fraction of what the percentage-based cut alone adds up to on Skool, before even counting the fixed platform subscription on top of it.

A Framework for Running Your Own Numbers

Rather than quoting a fixed set of figures that go stale the moment either platform adjusts its rates, here is the structural framework to apply with your own numbers, whatever they happen to be today.

1. Calculate your monthly recurring revenue. Your member count multiplied by your average monthly price.
2. Apply the processing rate to that revenue. This cost is identical whether you are on Skool or self-hosted, since the processor sets the rate either way.
3. Add Skool’s flat subscription on top, for the Skool total. This is the one cost self-hosting does not carry.
4. For the self-hosted total, add your hosting tier cost and your plugin licenses, both of which are flat or grow in large steps rather than continuously.
5. Compare the two totals at your current member count, then again at double and five times that count. Watch how the gap between the two totals changes as you scale, that trendline matters more than the number at any single point in time.

Run this once with your actual numbers and you will see the same pattern that holds across nearly every coaching, course, or membership community: the processing cost is a wash between the two options, and everything else in the comparison, the flat subscription plus whatever growth in that subscription, tips increasingly in favor of ownership as your community succeeds. The platforms with a genuinely low member count and low price point are the only scenario where the flat subscription’s absolute cost is small enough that the comparison stays close, and even then, the ownership question (who controls your member data, your pricing, your ability to keep running if the platform changes terms) does not disappear just because the near-term numbers are similar.

A Worked Example in Relative Terms

Numbers make this concrete even without attaching a specific currency amount to them. Picture your monthly membership price as one unit. A community of 500 members generates 500 units of monthly revenue. The processing cut, being a percentage, takes the same proportional bite regardless of whether you are on Skool or self-hosted, so that piece is a wash between the two paths and can be set aside entirely for comparison purposes.

What is left is the platform’s flat subscription on one side, and the hosting-plus-plugin cost on the other. At 500 members, both of those numbers are small relative to your total revenue, so the comparison feels close. Now grow the same community to 5,000 members, ten times the size. Your revenue grows ten times. The Skool subscription does not grow ten times, it is still one flat fee, but the processing cut, being a percentage of a much larger number, is now a genuinely large recurring cost. Meanwhile the self-hosted hosting bill has grown only by whatever step increase was needed to handle ten times the traffic, typically one or two tier upgrades, nowhere close to a proportional ten-times increase. The self-hosted total stays a small, shrinking fraction of your revenue as you scale. The Skool total, dominated by the percentage cut, grows in lockstep with your success.

This is the entire argument compressed into one observation: a percentage-of-revenue cost structure and a mostly-fixed cost structure diverge more the larger your revenue gets. Scale is exactly the condition under which owning your platform pays off most, which is the opposite of what the simple, friendly, flat-looking pricing page implies at first glance.

Common Objections to the Self-Hosted Argument

“I am not technical enough to run WordPress.”

This was a much stronger objection a decade ago than it is now. Managed WordPress hosts handle server administration, security patching, and backups as part of the hosting itself. The remaining technical work, installing a handful of well-documented plugins and configuring membership tiers, is closer to a weekend project with a good guide than a software engineering task. And the alternative to learning this once is paying a percentage of your revenue indefinitely to avoid ever learning it, which is a real tradeoff worth being honest with yourself about rather than assuming the technical barrier is higher than it actually is.

“My own hosting could go down too, so what’s the real advantage?”

True, and worth planning for with a reputable host and a backup routine. But downtime risk is not unique to self-hosting, Skool has had its own outages and support delays, documented in the same reviews cited above. The difference is what happens after an incident. A self-hosted outage is something you can diagnose, escalate to your host directly, and fix on your own timeline. A Skool outage or account issue puts you at the back of a support queue with no direct line to the people who can fix it, and no fallback environment to switch to while you wait.

“WordPress needs maintenance too, so the cost isn’t really flat.”

Correct, and this is accounted for in the framework above as the maintenance line item, not ignored. The distinction is that maintenance effort scales with the complexity of your setup, not with your member count. A 5,000-member community on a well-configured stack needs roughly the same maintenance attention as a 1,000-member community on the same stack, just running on a larger hosting tier. Compare that to a percentage-of-revenue fee, which by definition scales directly with your member count and your prices, and the asymmetry is the whole point.

How Platform Risk Compounds With Revenue

There is a version of this argument that has nothing to do with fees at all. The larger your community grows on a hosted platform, the more you have to lose if that platform bans your account, changes its terms, or shuts down a feature your business depends on. A creator with a small test community can absorb that risk easily. A creator whose entire recurring revenue lives inside one hosted platform’s database is exposed to a single point of failure that grows more consequential every month the community keeps growing.

This is not a hypothetical. The Trustpilot pattern cited earlier, accounts banned with no warning after years of active use, is precisely this risk materializing for real creators. The size of what they lost was proportional to how successful their community had become on the platform. Ownership is not just a cost argument, it is a way of making sure your biggest wins do not simultaneously become your biggest points of exposure.

Matching the Decision to Your Business Stage

Put the framework, the objections, and the risk argument together and the decision maps fairly cleanly onto where your business actually is right now, rather than requiring a single universal answer.

If you are validating whether a paid community concept works at all, optimize for speed. A hosted platform gets you a paying community this week instead of next month, and the fee structure barely matters yet because your revenue is still small. If you have validated the concept and are actively growing toward a meaningful membership base, this is the window to migrate, before the platform’s cut has grown large enough that switching feels painful, and before your member count has grown large enough that a migration becomes a bigger project than it needs to be. If you already have a large, thriving community on a hosted platform, the math still favors migrating, it simply means the project is bigger and the payoff, once complete, is proportionally larger too.

What Skool Does Well (Being Honest About This)

A fair cost comparison requires being honest about why people choose Skool in the first place. It is genuinely fast to launch. You can go from zero to a paid community in an afternoon. There is no hosting to configure, no plugins to update, no developer to hire. For someone who has never built a website and just wants to sell access to a community, Skool removes enormous friction.

The onboarding flow is clean. The course and community combination is native. The gamification system (points, leaderboards) works out of the box. And because Skool has a large base of existing creators, there is some discovery benefit from appearing in the Skool marketplace.

If you have a small number of members and you are testing a new idea, the low entry point is reasonable. The structural math does not go badly wrong until you start collecting real revenue and have something to lose if the platform bans your account.

The Trust Problem

The Skool Trustpilot page is worth reading before you commit. As of mid-2026, the score sits at 1.9 out of 5, based on reviews that cluster around a few consistent themes.

• Accounts banned with no prior warning and no explanation, often after years of use
• No way to export member data, payment history, or community content after a ban
• Support tickets going unanswered for weeks while the community is inaccessible
• Charges continuing after cancellation requests
• Refund requests denied in cases where the platform itself caused the service disruption

These are not isolated complaints. The pattern in the reviews is consistent: the product works fine until it does not, and when it stops working, there is no support path that moves at the speed your business needs.

A community platform that holds your paying members, your content library, and your recurring revenue is not an area where you can afford a slow support response. When your members cannot log in, every hour of downtime is revenue you have to refund and trust you have to rebuild.

Features You Do Not Get on Skool

Beyond the cost comparison, there are capabilities that self-hosted WordPress provides that Skool simply does not offer. Some of these matter more than others depending on your use case.

SEO and Long-Term Content Value

Discussions on Skool are private and behind a login. Search engines cannot index them. Every question your members ask, every answer your team gives, every thread that documents your community’s knowledge, none of it exists for organic search.

On WordPress with Jetonomy or BuddyPress, you choose what is public. You can make your forum threads indexable. A question answered publicly once can drive inbound traffic for years. Fly.io’s community forum, n8n’s forum, Cursor’s support community, all of these generate organic traffic because they are built on open platforms with indexable URLs.

Custom Checkout and Upsell Flows

Skool has one checkout flow. You can set a price and a free trial period. You cannot A/B test checkout pages, offer order bumps, apply coupon codes with complex conditions, or integrate with external email marketing automation at a trigger level. WooCommerce Subscriptions with CartFlows or a similar tool lets you build checkout flows that would be impossible on Skool.

Data Portability

Your WordPress database is yours. You can export every post, every comment, every member record, every transaction. You can move hosts, clone environments for testing, and rebuild from scratch if you need to. Skool offers no equivalent. If you leave Skool, or Skool leaves you, the data question is an open one.

Integration Depth

WordPress integrates with almost every tool a creator business uses: Zapier, Make, ConvertKit, Mailchimp, Klaviyo, HubSpot, ActiveCampaign, Stripe, PayPal, Lemon Squeezy, LearnDash, LifterLMS, Tutor LMS. Skool has a Zapier integration and its own API but the depth is not comparable. If your business has a technology stack, WordPress fits into it. Skool asks your stack to fit into Skool.

Migrating Off Skool: What Is Involved

If you are already on Skool and thinking about moving, the process has a few moving parts but is not as complex as it sounds.

What You Can Export

Skool allows you to export your member list as a CSV. This gives you names, emails, and join dates. You do not get payment history in a portable format, and you do not get community posts or discussion threads.

The Migration Steps

1. Export your member CSV from Skool before you cancel anything
2. Set up your WordPress environment (hosting, WordPress, BuddyPress, Jetonomy, WooCommerce Subscriptions)
3. Create membership tiers in WooCommerce that match your current Skool pricing structure
4. Import your member list and send a migration email with a dedicated onboarding link
5. Offer an incentive, a free extension of their current term or a modest discount, to members who complete migration within 30 days
6. Run both platforms in parallel for 30 to 60 days while members transition
7. Cancel your Skool subscription after the parallel run period ends

The parallel run period matters. Some members will be slow to move, and you do not want to lose revenue while migrating. Keep Skool active, post regularly in both places, and set a clear deadline for when the Skool community goes read-only.

Re-creating Courses and Content

Course content can usually be exported as video files and reposted. Skool does not lock your video files if you hosted them externally (via Loom or Vimeo). If you uploaded directly to Skool, you will need to download each lesson video manually before canceling. Text content can be copy-pasted. There is no automated export path for community posts, so treat that content as a fresh start and use the migration as an opportunity to restructure your curriculum.

Who Should Consider Self-Hosting

Not everyone should migrate off Skool today. The decision depends on where you are in your community’s lifecycle.

Self-hosting makes sense if you have a meaningfully sized paying membership already, your community is the central asset of your business (not a side product), you want your forum threads to rank in search, you need custom checkout or integration capabilities, or you want to eliminate platform risk from your revenue.

Staying on Skool makes sense if you are still testing your community concept, you have a small number of paying members and the launch speed matters more than the long-term cost structure, or you do not have a developer and cannot afford a build right now.

The crossover point in the framework above tends to arrive earlier than most creators expect, often well within the first year once a community has real paying traction. Below that point, the flat subscription dominates and the difference is modest. Above it, the compounding advantage of self-hosting grows every year.

The WordPress Stack That Replaces Skool

The build that most closely matches and exceeds Skool’s feature set uses the following components.

WordPress core provides the foundation. BuddyPress adds member profiles, groups, private messaging, and activity feeds. Jetonomy adds the forum layer with Q&A mode, accepted answers, trust levels, and threaded discussions built for both community engagement and customer support use cases. WooCommerce handles the store, and WooCommerce Subscriptions manages recurring billing, failed payment retries, trial periods, and subscription management.

For courses, LearnDash integrates cleanly with BuddyPress and WooCommerce, and Learnomy is worth evaluating directly if you are building the course side from scratch rather than retrofitting an existing LMS, since it folds course sales, certificates, and memberships into one platform rather than requiring a separate checkout bridge. For media hosting, Bunny.net delivers video at a fraction of the cost of Vimeo or Wistia. For gamification, BuddyPress Points or WB Gamification can replicate Skool’s leaderboard mechanics without a per-integration fee. For email, Postmark handles transactional delivery and you can use ConvertKit or Mailchimp for broadcast.

Nothing in this stack is exotic. These are mature, well-documented tools with large support communities and years of active development. None of them can ban your account and delete your community.

The Rent-Versus-Own Argument, Restated

Strip away every specific number and the argument comes down to one structural fact: a hosted platform that takes a percentage of every transaction is, by construction, a business partner that gets paid more the more successful you become, forever, with no point at which the relationship converts into something you own outright. A self-hosted stack is the opposite: the cost is front-loaded into a build and settles into a comparatively flat, predictable maintenance rhythm, while everything you build on top of it, your member list, your content, your brand, remains fully yours regardless of how large the community grows.

Neither model is wrong for every creator. A community still in its testing phase benefits from the speed of a hosted platform even knowing the economics tilt against it later. A community that has found real traction and plans to run for years is choosing, every month it stays on a percentage-of-revenue platform, to keep paying rent on a business it could otherwise own.

Getting Started

Apply the framework above to your own member count and price point and see where the crossover point falls for your specific community. The shape of the answer rarely changes: the processing cost is the same either way, and everything else compounds in favor of ownership as you grow.

If you are already past that crossover point and want to understand what a migration would look like for your specific setup, get in touch. We build and migrate communities off Skool, Circle, and Mighty Networks onto WordPress stacks that you own and control. We can usually scope a migration in a single call and deliver a running environment in 30 days.

The subscription was never the real problem. The problem is what a flat number on a pricing page does not tell you about how the real cost behaves once your community starts to grow.