The default decision for plugin founders is to build for Elementor first. The reasoning is straightforward: Elementor has roughly 5 million active installs. If you build an extension there, you have the largest addressable market. The logic is clean, the decision is fast, and it turns out to be wrong for most extension types. The mistake is not building for Elementor specifically – the mistake is treating install base as the primary selection criterion at all. For extension makers, the metrics that actually determine revenue per install look nothing like raw install counts.

The Install Base Numbers in 2026

Let’s start with where the ecosystems actually stand. Elementor sits at approximately 5 million active installs. That number has been roughly stable for two years – the explosive growth phase that took it from 1 million to 5 million happened between 2018 and 2022. The install base is large, but it is not growing at the rate it once was.

Beaver Builder has around 700,000 to 800,000 active installs. It has not grown dramatically, but it has not shrunk either. Its install base is characterized by longevity: agencies that adopted it five years ago still use it because they built custom modules and client workflows around it. Churn is low.

Bricks Builder launched its 1.0 in late 2021 and now sits around 80,000 to 100,000 active installs. That number looks small compared to Elementor but the trajectory is steeper than any other builder in the ecosystem right now. The critical difference: Bricks is paid-only, no freemium tier. Every install represents a buyer who paid money to build websites, not someone who grabbed a free plugin and has not opened WordPress since February.

Native Gutenberg blocks – meaning the WordPress block editor without a third-party builder layer – represent the largest distribution surface of all, but it is not one ecosystem controlled by a single vendor. Every WordPress site runs Gutenberg. The install count is effectively equal to WordPress’s 40%+ CMS market share. For extension makers targeting this surface, the competition model is different: you are building for a standard rather than an ecosystem, which changes both the distribution math and the monetization mechanics.

Divi sits around 800,000 to 900,000 active installs through Elegant Themes memberships and standalone licenses. Like Beaver Builder, it skews toward agencies and serious buyers, but its architecture is aging and its growth has flattened significantly since the Gutenberg push began. For extension makers, Divi’s closed module system and the declining investment Elegant Themes appears to be making in the builder relative to their other products make it a poor first target in 2026.

Oxygen Builder is worth a brief note. It has a smaller but deeply technical install base – serious developers who chose Oxygen precisely because it gives them more direct control than any drag-and-drop builder. Oxygen extensions command high prices and see strong renewal rates. The market is small but the buyer quality is exceptional. This same pattern now applies, with higher momentum, to Bricks.

Install Base vs. Intent: Why Raw Numbers Mislead

An Elementor install in 2026 represents something quite different from an Elementor install in 2019. In 2019, Elementor was capturing developers, agencies, and serious site builders. Today, the install base includes a substantial layer of users who installed the free version, built one portfolio page, and have not actively used it since. These installs generate zero revenue for the extension ecosystem.

Bricks Builder installs represent a fundamentally different kind of user. You cannot accidentally have Bricks installed. There is no free tier to stumble into. A Bricks install means someone researched page builders, chose to pay for a tool positioned explicitly for professional developers, and is building sites with it. The intent signal is 10 to 15 times stronger per install than the Elementor average.

Beaver Builder installs have a similar quality premium. The user base skews toward agencies with long client lists, freelancers who have invested in custom modules, and site builders who prioritized stability over features. These users buy extensions because their clients pay for quality outcomes. An extension that makes their workflow 20% faster is worth $100 per year without much deliberation.

This matters for extension makers in a direct way. If you build an addon for Elementor’s 5 million installs, the realistic buyer pool after filtering out inactive freemium accounts and low-intent hobbyist installs is probably 500,000 to 800,000 active professional users. If you build for Bricks’ 90,000 installs, the realistic buyer pool is most of them – these are professional builders who actively look for tools that solve real workflow problems. The addressable market is not 50 times smaller than Elementor. It is 3 to 5 times smaller, with a much higher conversion rate.

There is a second dimension to intent that matters even more for long-term LTV: problem specificity. Elementor’s large audience has a wide range of use cases, which means extensions that solve very specific problems face a discovery challenge – the pool of people with that exact problem is diluted across a large install base with many competing tools. Bricks’ developer-focused audience has more uniform workflows and more specific, articulated needs. Extension makers who build for Bricks can target narrower problems and still reach meaningful scale within the community.

Raw install count is the wrong metric for extension makers. The right metric is active professional installs with purchasing intent – and that number looks very different across ecosystems.

LTV Per Install: What Extension Makers Actually Earn

Revenue-per-active-install is the number that should drive ecosystem selection, and almost no founder calculates it before committing to an ecosystem. Here is how the math looks across the four main surfaces, based on pricing patterns from established extensions in each ecosystem.

EcosystemRealistic Active Pro InstallsTypical Extension Price (Annual)Addressable Revenue per 1% Conversion
Elementor~600,000$49-$79~$35,000-$47,000
Beaver Builder~650,000$79-$149~$51,000-$97,000
Bricks~85,000$79-$199~$67,000-$169,000
Native BlocksDepends on use case$49-$299Unbounded ceiling, lower floor

A few things stand out in this table. Elementor’s large install base does not translate into proportionally higher addressable revenue at the same conversion rate, because the addressable professional-tier pool is not 50 times Bricks – it is closer to 7 times. Meanwhile, Bricks extensions command higher prices because buyers are developers who price-compare on capability and support quality, not on the cheapest option that clears a minimum feature bar.

Beaver Builder has historically been the best-kept secret in the extension ecosystem. Its agency-heavy user base has long renewal cycles. An extension sold to a Beaver Builder agency in 2021 is still renewing in 2026 if the support has been decent. LTV per customer is often 3 to 5 years rather than 1 to 2 years as seen in Elementor’s more churn-prone professional segment.

Native blocks is the wildcard. There is no single company controlling distribution the way Elementor does. A well-built Gutenberg block plugin gets discovered through WordPress.org search, through theme bundling, and through agency referrals. The TAM is effectively all of WordPress, but competition is also broader. The ceiling is higher, the floor is lower, and the customer acquisition cost is different because you are not marketing to a defined ecosystem community – you are marketing to everyone on WordPress.

The hidden cost in the LTV calculation that many founders miss is support cost per customer. Elementor’s mixed-intent install base generates higher support volume per paying customer because the audience spans from professionals who know what they want to hobbyists who are still learning the basics of WordPress. Bricks customers typically know exactly what they need from an extension and submit fewer “how do I use this” tickets. The support economics are materially different, and for a solo or small-team extension operation, support cost is often the difference between profitable and not.

Raw install count is the wrong metric for extension makers. The right metric is active professional installs with purchasing intent - and that number looks very different across ecosystems.
Raw install count is the wrong metric for extension makers. The right metric is active professional installs with purchasing intent – and that number looks very different across ecosystems.

The AI-Era Risk: Which Ecosystems Are Closing the Extension Market

The page builder ecosystem is not static, and AI integration is accelerating a split that will reshape extension economics over the next two to three years.

Elementor has been aggressively integrating AI into core. Elementor AI (launched 2023, expanded 2024-2025) brings text generation, image creation, layout suggestions, and code writing directly into the builder interface. Each capability that moves into core is a capability that an extension maker can no longer sell as a standalone product. If Elementor’s AI can generate a contact form with custom styling in 30 seconds, the market for contact-form-builder addons for Elementor shrinks. This pattern will continue. Elementor’s business model requires them to add AI capabilities to justify their pricing and compete with newer builders – and every AI feature they add narrows the addressable market for third-party extensions.

This dynamic was the core of Robby McCullough’s commentary on Beaver Builder’s approach to AI (WP Tavern, 2025). Beaver Builder has taken a deliberately different stance: integrating AI as an optional workflow enhancement rather than a core feature that displaces third-party tooling. The explicit philosophy is that AI should help builders think and prototype faster without making the extension ecosystem redundant. Whether that is a principled decision or a competitive positioning against Elementor is secondary – the practical outcome for extension makers is that Beaver Builder is not systematically closing the market for extensions that solve specific workflow problems.

Bricks’ community has been more measured about AI integration. The builder’s architecture – which leans heavily on developer-defined custom code, query loops, and dynamic data – does not lend itself to broad AI feature insertion the way a visual drag-and-drop tool does. AI can assist with CSS generation and code snippet writing within Bricks, but the core workflow still requires human judgment about structure, queries, and performance. This means the extension market for Bricks-specific tooling (query utilities, dynamic data bridges, performance tools) is not at immediate risk of being absorbed by AI features.

Native Gutenberg blocks face the most complex AI picture. Automattic has integrated AI writing assistance and basic layout suggestions, but the block editor’s modular architecture means that third-party blocks are not being displaced the way addons to a closed ecosystem can be. The risk for native block extension makers is different: it is not that AI closes your market, it is that AI makes your block category more competitive by lowering the technical barrier for new entrants. If anyone can build a competent block with AI-assisted code generation, the number of competing blocks increases. Differentiation has to come from support quality, documentation, integrations, and update cadence – not from technical execution alone.

The longer-term AI risk that applies across all ecosystems is the emergence of natural-language site builders that bypass the traditional page builder layer entirely. Tools that let users describe a layout and generate it directly are still in early stages, but they represent a structural threat to the extension market because they may eventually replace both the builder and the extension. This timeline is 3 to 5 years out at minimum, but it is worth factoring into ecosystem selection now: building for an ecosystem that is actively investing in AI resilience (Beaver Builder) or that has a modular architecture that AI cannot easily subsume (native blocks, Bricks) gives an extension more defensible runway than building for an ecosystem that is becoming an AI-first product (Elementor).

Decision Rules by Extension Type

Given the install-intent split, LTV-per-install differences, and AI risk profiles, here is how extension type should drive ecosystem selection.

Form Builder and Lead Capture Extensions

Build for native blocks first, with Elementor as a secondary integration. Form functionality is one of the areas Elementor AI is actively encroaching on, and Elementor’s acquisition of third-party form tooling capacity through core AI features will continue. Native blocks form extensions have a larger addressable market, and WordPress.org distribution means lower CAC. The competition is heavier, but a well-maintained native blocks form extension with solid documentation will find a durable market across Gutenberg-native themes and Gutenberg-native builds.

Ecommerce and WooCommerce Integration Extensions

Native blocks plus Bricks is the right combination. WooCommerce has been moving toward block-based checkout and product components, and building native integration with that trajectory is the highest-leverage position for ecommerce extension makers. Bricks’ developer audience is building client stores and needs reliable WooCommerce integration components that work with dynamic data queries – this is a real purchase driver in that community. Elementor’s WooCommerce Builder feature has been expanding and partially cannibalizing the third-party ecommerce extension market.

Membership and Community Extensions

Native blocks with BuddyPress or BuddyBoss integration. This category is almost entirely served by the Gutenberg-native ecosystem rather than page builder ecosystems. Membership plugins (MemberPress, Restrict Content Pro, Paid Memberships Pro) have their own extension systems, and the integration surface is the WordPress block editor. Page builder-specific membership extensions have limited markets because the use case is primarily content restriction and member dashboard building – neither of which benefits strongly from a page builder layer. Build for native blocks and design for LMS/community plugin compatibility.

Layout and Design Extensions

Bricks, with Beaver Builder as a high-LTV secondary market. Layout and design extensions – custom post type builders, dynamic data bridges, conditional display tools, grid layout utilities – are where the Bricks and Beaver Builder markets are most active and most willing to pay. These tools solve precise technical problems for professional site builders and are not being absorbed by AI features in either ecosystem. Price the Bricks version at $99 to $149 per year, the Beaver Builder version at $79 to $129, and you have a defensible product in an ecosystem where buyers renew consistently.

What It Actually Costs to Migrate an Extension 18 Months In

The calculation above matters most for founders at the start, but many extension makers are 12 to 24 months into an Elementor-first build when they realize the economics are not working. The migration cost is worth understanding explicitly.

An Elementor extension built around Elementor’s Widget API (the standard approach since 2018) is coupled to Elementor’s rendering lifecycle, its live preview system, and its control registration patterns. Migrating to Bricks means rewriting the UI layer entirely – Bricks uses its own element architecture with PHP-defined controls and JavaScript rendering hooks. The migration is not a port, it is a rebuild of the frontend interface with the same core logic underneath.

For a typical extension with 15 to 25 settings controls and a custom output renderer, expect 3 to 6 weeks of focused developer time to produce a Bricks version that passes quality review. Add 2 to 4 weeks for documentation, testing, and support tooling updates. The full migration cost is typically 8 to 12 weeks of developer time, which at agency rates represents $12,000 to $25,000 in opportunity cost or direct expenditure.

The migration cost for going from Elementor to native blocks is lower in some ways and higher in others. The block API (block.json, edit/save functions, useBlockProps) is more standardized than any page builder’s API. But converting a widget that depends on Elementor’s live preview system to a statically saved block means rethinking what the widget actually does at render time. Dynamic blocks (server-side rendering with PHP) can replicate most widget behavior, but the mental model shift is significant and there are subtle differences in how saved content is stored that affect existing customers on migration.

There is an additional migration cost that is harder to quantify: the cost of your existing customer base. An Elementor extension that has been on the market for 18 months has customers who have built client sites using your widget. A migration that requires them to update their sites is a support event and potentially a churn event. The way to manage this is through a compatibility shim that keeps the old Elementor version functional while you invest in the new ecosystem – but that doubles your ongoing maintenance cost until you can sunset the old version. Plan this into the migration budget from the start.

The right takeaway is not “never migrate” – it is that migration from Elementor to a better-fit ecosystem is a real capital expenditure, and building for the wrong ecosystem at launch means you will eventually spend that capital or accept the ceiling it imposes. Starting the ecosystem decision with LTV-per-install math is cheaper than discovering the ceiling 18 months into customer acquisition.

The Founder Economics of Plugin Distribution

Stepping back from the individual ecosystem decisions, there is a broader pattern worth naming: most plugin and extension founders optimize for discoverability before they have modeled revenue per install. Discoverability – getting your plugin in front of the largest possible audience – is valuable at the top of the funnel, but it does not determine whether the business that results is sustainable.

The plugins that have built durable, profitable businesses in the WordPress ecosystem over the last decade share a common pattern: they picked a customer type with a specific, recurring problem and built for that customer type exclusively. GravityForms did not try to be the form builder for every WordPress user – it built for developers and agencies who needed programmable, extensible forms. The price point that results from serving that customer type ($59 to $259 per year) reflects the value delivered to that specific segment, not the maximum number of users who might install a form plugin.

This same logic applies to ecosystem selection. Distribution-first product thinking requires picking a narrower target and serving it exceptionally well. Picking Elementor because it has the most installs is the equivalent of trying to be a form builder for every WordPress user. The market looks enormous until you discover that most of it does not pay, churns at high rates, and generates support costs that erode margin. Picking Bricks or Beaver Builder because those users have specific problems, budget to solve them, and low churn is the GravityForms move: smaller apparent market, better actual business.

The founders who build successful WordPress extensions in 2026 will be the ones who ran the LTV-per-install math before they wrote the first line of code for their builder integration. That calculation is not complicated – it requires knowing the rough size of the professional tier in each ecosystem, the typical price points extensions command in each community, and an honest estimate of conversion rate given your extension’s specificity. The number that comes out of that calculation almost always points somewhere other than Elementor-first.

The Next 30 Days: A Concrete Move for Misaligned Founders

If you have read this and recognize that your extension is in the wrong ecosystem, the immediate move is not to start a migration. The immediate move is to run the numbers on your current install base.

Pull your active license count and segment by renewal year. If more than 40% of your licenses are on their first year and renewal rates are below 50%, you have an ecosystem mismatch problem showing up in churn. If your support volume is high relative to revenue – more than 1 support ticket per $50 of ARR per month – you are serving a user base that is not the right fit for what you built.

The second move is to look at your competitors who have migrated to Bricks or Beaver Builder and check their changelog dates, their AppSumo or marketplace reviews, and their public pricing. An extension that launched a Bricks version in 2023 and has maintained it through Bricks 1.9 updates is a signal that the market is real and the support burden is manageable. The same quality signal applies when evaluating existing plugin install bases as acquisition targets – the buyer profile matters more than the raw number.

The third move is to post in the Bricks Builder Facebook group or Discord asking what extensions the community wishes existed. The response density and specificity of that request list will tell you more about purchase intent than any install count chart. A community that can articulate exactly what they need and why existing options fall short is a community that will pay for a well-built solution.

If you are starting fresh and have not committed to an ecosystem yet, do this before you write any integration code: build a landing page for your planned extension and post it in each builder’s community. Measure pre-launch signup rate per 1,000 community members. This is the cleanest A/B test available for ecosystem selection – it measures actual purchase intent from real members of each community, and it costs nothing except the time to write the landing page copy. The signal from that test will tell you which ecosystem to build for first.

The decision to build for a smaller ecosystem with higher intent is not intuitive when the conventional wisdom is to follow the biggest install base. But extension economics are not about the size of the user pool – they are about the concentration of buyers with specific problems, budget to solve them, and the discipline to renew annually. That profile describes Bricks and Beaver Builder’s professional developer segments better than it describes Elementor’s mixed-intent install base in 2026. The distribution math, once you actually run it, points in a different direction than most founders expect.

The economics of plugin distribution and the decisions that shape long-term revenue are part of what Wbcom Designs works through with founders building on WordPress. These decisions sit alongside the broader question of which software business models are viable in 2026 – a question worth reading before committing to a product strategy. If you are evaluating ecosystem fit for a plugin or extension you are building or planning to build, the custom plugin development work at Wbcom Designs puts these conversations at the center of the engagement – not as a side discussion, but as the first thing that determines whether a product can be a viable business. The analysis above is what that decision looks like from the inside of that work.