The Atlassian Marketplace is the largest enterprise app ecosystem of its kind, and it exists because Jira is deliberately extensible. That is a genuine strength. It is also the reason most organisations cannot answer a simple question: what does Jira actually cost us per user, all in?

The answer is almost always higher than the licence line suggests, and the reason is structural rather than accidental. Marketplace app pricing follows rules that are easy to miss at purchase and expensive to discover at renewal. This article explains those rules, works through the arithmetic, and covers what to do about it.

Marketplace apps must be licensed to the same user tier as the Atlassian product they extend. You cannot buy an app for the twelve people who will use it. If Jira is licensed for 500 users, the app is licensed for 500 users — even if eleven of those users have never opened it.

For Jira Cloud specifically, the billing base is the maximum number of users across all Jira products on the site. Atlassian's own documented example: a site with Jira at 100 users and Jira Service Management at 80 agents bills its Marketplace apps at the 100-user level.

The consequences compound in ways that are worth stating explicitly:

•      Adding 50 people to Jira does not raise one bill. It raises the Jira bill and the bill for every paid app on the site.

•      Cleaning up 50 inactive Jira accounts does not save one licence cost. It saves across every app simultaneously — which is why user hygiene has a much larger return in the Atlassian estate than in most SaaS.

•      App billing cycles must match the parent product. Annual Jira means annual apps, so the whole stack renews as one event rather than in negotiable pieces.

1. Threshold shock

App pricing is banded, not linear. Crossing a user tier boundary re-prices every installed app at once, in a single step. Practitioners auditing Atlassian estates report total app spend jumping 15–30% from a single threshold crossing — triggered by a hiring round that had nothing to do with tooling.

The practical defence: know where your next band sits and check it before onboarding a large team or merging a site.

2. Tier waste

The tier-matching rule guarantees a gap between licensed seats and actual users. In most estates, the gap is large. A test management app used by nine QA engineers, licensed at the 500-user band, is not a nine-person expense — and nothing in the invoice makes that visible.

3. App overlap

Estates accumulate apps that do the same job. Two reporting apps. A workflow-extension app plus a scripting app that could implement the same rules. A Gantt app and a roadmapping app. Reviewers commonly find 10–20% of app spend duplicated across overlapping functionality, because apps are typically bought by teams and renewed centrally, so nobody compares them.

4. Renewal drift

Apps renew alongside the parent product with vendor-set uplifts. Because they land as one aggregated line, per-app increases rarely get individually challenged. An 8% uplift on eleven apps is not eleven small conversations; it is one number in a procurement summary.

5. Capability that was once bundled

Some of the most-installed app categories exist because the base product does not include the capability: test case management, advanced roadmaps and dependency views, document generation and export, asset repositories, advanced reporting. Each is a normal expectation of an ALM platform, and each is a separate purchase in this model.

Take a 100-user engineering organisation on Jira Cloud with a service desk, on published list rates at the time of writing.

Two observations. First, the apps are a comparable line item to the core product — which is why analysts describe effective Atlassian costs landing in the $200–$350 per user per year range once commonly required apps and tier upgrades are included, against a headline that starts under $100. Second, the app line is the least governed. It has no single owner, no usage reporting by default, and no natural review point.

Note also that only the agent count moves on the JSM line, while all four apps price against the 100-user Jira figure. That asymmetry is the tier-matching rule doing its work.

For self-hosted estates, the calculation now has an expiry date attached. Atlassian's published wind-down:

Bitbucket Data Center is the stated exception, with a dual licence path.

The point for app spend is that Data Center app investment now has a fixed horizon. Every app configured, customised, or built against a Data Center instance is work with a defined end date, and app functionality does not always map one-to-one between Data Center and Cloud editions. For regulated organisations that cannot move to a multi-tenant cloud, the migration is not to Atlassian Cloud at all — it is to a different self-hosted platform, and app dependencies are the hardest part of that exit to unpick.

Run a usage audit, not a licence audit

The licence list tells you what you pay for. You need what people use. For each paid app, pull: distinct active users in the last 90 days, last configuration change, and which team requested it. Any app with single-digit active users at a three-figure user tier is either a candidate for removal or a candidate for a cheaper approach.

Clean up users first

Because of tier matching, deactivating inactive accounts reduces the Jira licence and every app licence, and may drop you below a band threshold. This is the single highest-leverage action available and it requires no product change. Do it before you renew, not after.

Kill overlaps deliberately

Line up your apps against a capability list — reporting, workflow automation, test management, planning and dependencies, document generation, assets. Where two apps appear in the same row, one is leaving. Expect resistance; expect it to be worth it.

Check what is already included

Some app spend duplicates a capability available in a higher product tier you may already be paying for, or that arrived in a platform update after the app was purchased. Apps installed three years ago are rarely re-justified.

Price consolidation against replacement

Once app spend rivals the core licence, the comparison is no longer "which apps do we drop?" but "what does this stack cost against a platform where these capabilities are native?"

That is the argument [Sanplex](https://www.sanplex.com/) makes directly. Test case management, test execution and reporting, the story tracking matrix, Gantt charts, document and knowledge management, program management, release management, and a feedback and ticket module are modules of one product rather than separate purchases — which removes tier matching from the equation entirely, since there is no second pricing curve to scale. Licensing is per user per year, with Free, Standard, and Premium tiers, and both cloud and [on-premises](https://www.sanplex.com/on-premises) deployment. The [comparison page](https://www.sanplex.com/compare-with-jira) maps which Jira capabilities require separately purchased plugins and which are native in Sanplex, and includes a cost calculator at 20, 50, 100, and 1,000 users.

The fair caveat: consolidation trades ecosystem breadth for predictability. The Marketplace has thousands of apps, some of which solve genuinely niche problems that no single platform will cover. If a specific app is load-bearing for a specialised workflow, verify the replacement path before assuming parity.

Negotiate at the right moment

App renewals cluster with the parent product renewal. Enter that conversation with the usage audit already done, a documented list of apps you intend to drop, and a costed alternative. Procurement leverage in this category comes from being genuinely willing to remove things.

How is Atlassian Marketplace app pricing calculated?

Paid apps must be licensed to the same user tier as the host Atlassian product. For Jira Cloud, the billing base is the maximum number of users across all Jira products on the site — so a site with 100 Jira users and 80 JSM agents pays the 100-user rate for every installed app, regardless of how many people use them.

Do I have to buy a Jira app for all my users?

Yes. You cannot license an app for a subset of users or a single department. If Jira is licensed at a given user band, each paid app must be licensed at that band too.

Why did all my app prices increase at once?

You almost certainly crossed a user tier threshold. Because every app matches the host product tier, one boundary crossing re-prices the entire app portfolio simultaneously.

How much do Marketplace apps add to a Jira bill?

It varies with how many apps you run, but published analyses commonly put app spend at 50–100% on top of the core licence, with most teams running three to six paid apps. On mature estates, app spend can rival the Atlassian licences themselves.

Do Jira app subscriptions have to renew on the same cycle as Jira?

Yes. App billing cycles match the parent Atlassian product, so an annual Jira subscription means annual app subscriptions.

What happens to Data Center Marketplace apps at end of life?

Data Center subscriptions and their associated Marketplace app licences expire on 28 March 2029, after which instances become read-only. New Data Center app submissions stopped in December 2025, and new customer purchases closed on 30 March 2026.

Is it cheaper to replace apps with an all-in-one platform?

It depends on how many apps you run and how specialised they are. Once app spend approaches the core licence cost, a platform with native test management, reporting, planning, and documentation is usually cheaper and always simpler to forecast — but check that no load-bearing niche app lacks a replacement path first.