Pricing Wiki
Add-ons & modular packaging
Sell a strong core product, then charge for optional add-ons/modules that match distinct customer needs.
Snapshot
What it is
A pricing/packaging approach where customers buy a core offer, then optionally purchase add-ons (modules) to tailor the product to their needs.
Why it matters
Done well, it (1) captures willingness-to-pay differences, (2) keeps entry plans simple, and (3) creates repeatable expansion paths.
When to use
When your customer base is heterogeneous (some want simple, some want complex) and you've reached Product-Market Fit with a stable core offering.
Key takeaways
Keep the Core Clean: Don't clutter the base tier with niche features.
Don't "Average" Your Customers: If you sell to diverse industries, a static tier structure will leave money on the table. Use add-ons to monetize distinct value dimensions (not minor toggles).
Add-ons work best when they're independently valuable and easy to explain.
Beware the "Hydra": Spinning out every new feature as an add-on is a lazy monetization strategy. It increases Customer Acquisition Cost (CAC) because sales reps have to explain complex menus, and it increases Cost to Serve. Periodically re-package add-ons into tiers to clean up the mess.
On this page9 sections
What are add-ons and modular packaging?#
The Core offer: The base product customers must buy to solve the primary problem.
Add-ons: Distinct features, services, or capabilities sold separately on top of a core product or tier. They allow customers to "top up" their purchase to meet specific needs without forcing a full upgrade to a higher tier.
Modular Packaging: A flexible architecture where the product is broken down into distinct components (modules) that can be mixed and matched for a specific use case or persona (e.g., a "Compliance Module" or "Marketing Suite"). Unlike a rigid Good/Better/Best tier structure, modular packaging allows customers to "build their own" solution by selecting only the specific capabilities they need.
Add-ons vs Modular Packaging#
Note: sometimes people use add-ons and modules interchangeably. On this site, we distinguish them.
- If the feature defines who the customer is (e.g., "I am a Supply Chain Manager"), it is a Module.
- If the feature defines how much power the customer needs (e.g., "I need more speed/storage/security"), it is an Add-on.
While both concepts involve selling features separately from the core offering, they serve different strategic functions regarding market segmentation and buyer behavior.
| Feature | Add-ons | Modular Packaging |
|---|---|---|
Market Context | Best for homogeneous markets with slight variance. Most people want the same core product, but a few power users need extra storage, and Enterprise users need SSO. | Best for heterogeneous markets. One customer needs "Inventory Management" while another needs "Point of Sale." Their needs are too diverse to fit into a single Good/Better/Best ladder. |
Sales Motion | Vertical/Upsell. "You are on the Pro plan; would you like to add Analytics for $50?" It is a "top-up" decision. | Consultative/Configuration. "Let's look at your unique needs and select the specific modules that solve them." |
Why they belong together:
- Shared Goal: Both strategies aim to solve the problem of heterogeneity—the fact that different customers value different things. They both move away from the rigid "one-size-fits-all" or strict Good/Better/Best hierarchies.
- Operational Overlap: In practice, the line is often blurred. A "Module" is often technically implemented as a large "Add-on" in billing systems.
- The "Core + Extension" Architecture: Both rely on the concept of a "Base" or "Platform" fee (to cover CAC and core R&D) plus variable elements (modules/add-ons) to capture upside.
Mental model#
The "Core + Lego" System
Think of your product not as a single block, but as a Base Platform (the core features required for the product to function) surrounded by Lego Blocks (Add-ons/Modules).
- Vertical Strategy (Tiers): You force customers to buy a pre-built Lego castle (Small/Medium/Large).
- Horizontal Strategy (Add-ons/Modules): You sell the base castle, and let them buy the "Motorized Drawbridge" (a high-cost capability, considered as a module) or "Moat" (a niche feature, considered as an add-on) separately if they need it.

Rules of thumb#
- One add-on = one sentence. If you can't explain it simply, it's probably a bundle or a tier.
- One add-on = one buyer. Aim for a clear economic buyer (IT, Finance, Ops) rather than "everyone."
- The 20/80 Rule: Only 20% of your users should need a specific add-on. If 80% need it, it's a core feature and you are "nickel-and-diming" your customers; then it becomes a Killer feature that reduces conversion.
- The Pricing Anchor: Add-ons should typically be priced at 15–30% of the base plan price to ensure they feel like an "upsell" rather than a "new purchase."
- Fewer, bigger modules beats many tiny toggles. Start with 2–5 high-value modules. Do not offer more than 3–5 standalone add-ons/modules at the mass-market level. If you have more, group them into an "Enterprise Pack" or "Security Suite" to reduce decision paralysis.
Why do add-ons and modular packaging matter?#
- Capturing Heterogeneous Demand: If your market has high variance in needs (e.g., one customer needs Analytics but not Security; another needs Security but not Analytics), standard tiers will fail. Modular pricing maximizes revenue by allowing each customer to pay for exactly what they value.
- Monetizing "Niche Leaders": Some features are highly valued by a small segment of users (High Willingness to Pay) but irrelevant to the majority (Low Popularity). If you bundle these into the core product, you bloat the price for everyone; if you sell them as add-ons, you capture pure profit from the power users.
- Wallet Structuring: Large enterprises have different budgets (e.g., IT budget vs. Marketing budget). Modular packaging allows you to sell different parts of your product to different stakeholders within the same company, effectively maximizing the total contract value.
Key Facts
Simplicity beats optionality
McKinsey found companies with restrained structures — three tiers, good/better/best, and fewer than five add-ons — were nearly 30% more likely to report effective pricing and discount control than those with highly complex packaging. Modularity pays until the menu gets long.
McKinsey, The art of software pricing51.5% revenues
In airline "ancillaries" (add-ons), some carriers have earned ~51.5% of revenue from add-ons (e.g., Spirit, 2022).
IdeaWorksCompany YearbookExpansion only matters at scale
OpenView's benchmarks show expansion contributing just 14% of ARR below $1M, rising to 38% at $20-50M and 40% above $50M. Building an add-on catalogue before you have an installed base to sell it into is premature.
OpenView SaaS BenchmarksWorked example: when the sixth add-on starts losing money#
Base product at $500/month, 1,000 customers, six add-ons at $100/month each. Attach rates decay the way they almost always do:
| Add-on | Attach rate | Annual revenue | Fully-loaded cost | Contribution |
|---|---|---|---|---|
A1 | 42% | $504,000 | $85,000 | +$419,000 |
A2 | 31% | $372,000 | $85,000 | +$287,000 |
A3 | 19% | $228,000 | $85,000 | +$143,000 |
A4 | 11% | $132,000 | $85,000 | +$47,000 |
A5 | 6% | $72,000 | $85,000 | −$13,000 |
A6 | 3% | $36,000 | $85,000 | −$49,000 |
The $85,000 is not engineering. It is the standing cost of offering a module: billing configuration, entitlement logic, docs, support training, sales enablement, and one more row on a pricing page that every prospect has to read past.
Retiring A5 and A6 returns $62,000 a year and shortens the pricing page — and it moves the catalogue under the five-add-on threshold where McKinsey found companies were nearly 30% more likely to report effective pricing and discount control.
Where the break-even sits. At $1,200/year per attach, a module needs 71 customers to cover $85,000 — a 7.1% attach rate on a 1,000-customer base. That is the number to test a proposed add-on against before building it, and the reason attach rate belongs on the roadmap review rather than only in the revenue report.
One caveat on cutting. Attach rate is not strategic value. If A6's 3% are your five largest accounts, it is a retention feature wearing an add-on's clothes — fold it into the enterprise tier rather than deleting it. Check revenue concentration before you cut.
How do you implement add-ons and modular packaging step-by-step?#
Inputs you need#
- MaxDiff Analysis: Survey data identifying which features are "must-haves" (Leaders) vs. "nice-to-haves" (Fillers) for different segments.
- Feature Usage Data: Telemetry showing what % of your user base actually utilizes specific features.
- Cost-to-Serve Data: Identify features with high variable costs (e.g., SMS, storage, high-touch support).
Step-by-step
Define the "Core"
Strip your base plan down to the features that 80%+ of users interact with weekly. Core should solve a real end-to-end workflow for your primary segment.
Identify Add-on Candidates
Audit your feature set. List all features and filter them through the Add-on Rubric:
- Is it high cost? (e.g., SMS alerts).
- Is it niche? (e.g., Oracle Integration).
- Is it enterprise-only? (e.g., SSO).
Identify Module Candidates
Write 8–15 candidate capabilities and cluster into 2–5 modules where each module is a coherent job. Each module should be: separable, testable, and supportable. Avoid splitting a single workflow across core + add-on (frustration risk).
Price the Add-on/Module
Determine price based on the incremental value provided.
- Flat Fee: Simple, predictable. Good for features like "Advanced Reporting" module ($500/mo).
- Anchor to core price: Common starting point is +20–50% of core for a high-value module.
- Metric/Usage: Good for high-cost features (e.g., $0.01 per API call). See value metric and usage-based pricing. Aligns cost with revenue.
Metrics to monitor
Attachment Rate (Take Rate)
The % of customers who purchase at least one add-on. If <5% buy it, kill it or bundle it. If >80% buy it, it should probably be in the Core package.
Expansion MRR Percentage
Total revenue growth from existing customers via modules. Are existing customers buying modules later in their lifecycle (expansion)?
Sales Cycle Length
If sales cycles lengthen significantly after introducing modular pricing, your packaging is too complex for your buyers.
Risks & anti-patterns (and fixes)#
| Pitfall | Fix |
|---|---|
Nickel-and-Diming: Customers feel frustrated if they have to pay extra for every small feature. | Ensure the "Base" package is a complete, usable product, not a "crippleware" version. Use add-ons only for distinct high-value needs. |
The "Hydra" Complexity: Having 50 add-ons makes the checkout process a nightmare. | Consolidate low-selling add-ons back into tiers every 12–18 months; group add-ons into 2–5 logical Modules (e.g., "The Security Pack"). |
Hidden Costs: Selling a high-cost feature (like custom reporting) as a cheap add-on that explodes in maintenance costs. | Use "Wallet Structuring." Price high-cost modules on a "Cost-Plus" basis to ensure margin protection. |
References & Links#
Sources:#
- Baker, W. L., Marn, M. V., & Zawada, C. C. (2010). The Price Advantage. Wiley.
- Ghuman, A. (2021). Price to Scale. Independently published.
- IdeaWorksCompany. (2023). CarTrawler Yearbook of Ancillary Revenue 2023. IdeaWorksCompany.
- Lehrskov-Schmidt, U. (2023). The Pricing Roadmap. Independently published.
- Ramanujam, M., & Tacke, G. (2016). Monetizing Innovation: How Smart Companies Design the Product Around the Price. Wiley.
Frequently asked questions
01What is the difference between a "Tier" and a "Module"?
A Tier (Gold/Silver) is a vertical configuration; you buy one state. A Module is a horizontal building block; you can buy many (Base + Module A + Module B). Use Tiers for homogeneous customer bases; use Modules for heterogeneous bases with varied needs.
02How many add-ons should I launch with?
03Should add-ons/modules be available on every plan?
Not always. Common rule: allow "entry" add-ons on mid-tier+, keep premium modules for top tiers/enterprise.
04When is it too early to introduce add-ons?
If you are still finding PMF (less than $1M ARR), keep it simple. Complexity is the enemy of early-stage closing. Start modularizing when you see clear segments in your usage data.
05When do I fold an add-on into core?
When it becomes table stakes for your primary segment or when selling it separately adds more friction than revenue.
06How do I price services (onboarding/support)?
Treat them as add-ons. Even if you discount them to zero to close the deal, list them as line items with a price. This establishes value and prevents customers from treating your team's time as infinite/free resources.
Author
Dr. Sarah Zou
Independent economist · EconNova
Commercial strategy for technical products, with a focus on pricing, unit economics, and the operating choices behind the model.
About SarahTopics
Cite this page
Suggested citation
Zou, S. (2026). Add-ons & modular packaging. In Product, Packaging & Bundling. Pricing & Monetization Wiki. https://sarahzou.com/wiki/pricing/packaging-and-bundling/add-ons-modular
Open license
Reuse with attribution
This content is available for reuse. When referencing or republishing it, please credit Dr. Sarah Zou and link back to the original source.
Licensed under Creative Commons Attribution 4.0 International. You may share and adapt the material with appropriate credit.