Pay for the 20% You Use: Shrinking Your Atlassian App Footprint Without Losing the Workflow

How an honest audit and a focused custom Forge app turn pay-per-seat-forever into pay-once-you-own-it.

The bill that quietly grows

Most teams discover the cost of their Atlassian app footprint the same way they discover most operational debt. By the time it hurts, it has been hurting for a while.

Marketplace apps are billed per user. Every new hire raises the bill on every app you have ever installed. Every app you tried during a project, every trial a contractor talked you into, every tool that solved a problem two years ago is still on the invoice. Linear cost growth, with nothing pushing back the other way.

We see this with customers at every size:

• Small teams hit it when they realize the apps cost more than a junior engineer’s hours.
• Mid-sized teams hit it during a renewal cycle when the numbers no longer round down.
• Large enterprises hit it when finance asks why the Atlassian line item is growing faster than headcount.

The good news is that the same audit fixes all three.

The 80/20 of Marketplace usage

The pattern we find, almost every time we audit an instance, is the same.

Most teams use a small fraction of what they are paying for. Lots of apps installed during a past project, never decommissioned. Lots of premium features that nobody on the team can name. Lots of overlap, where two apps cover similar ground because they were bought by different people for different problems at different times.

The 20% that teams actually depend on is usually obvious to the people doing the work. They can name it in a five-minute conversation. The other 80% is paying for features that exist, technically, but might as well not.

That is the gap we close.

How to audit your own footprint

You do not need an engagement to do this. You need three lists and an afternoon.

Start with what you are paying for: every paid app, its tier, and the annual figure. Your Atlassian admin billing page has all of it. Then get usage: which apps are actually opened, by whom, how often. Some apps report this themselves. For the rest, ask the five people most likely to be power users, and watch what they say when you propose removing it. Finally, cross-reference. Any two apps whose descriptions overlap are worth an hour of scrutiny.

For each app, answer four questions with evidence rather than instinct:

• Is it essential, replaceable, or unused?
• Does it overlap with something else you already pay for?
• What fraction of its features does your team actually use?
• If it is replaceable, what would replacing it cost, and how long until that pays back?

The uncomfortable answers usually cluster around the same two or three lines on the bill.

Why custom Forge beats the Marketplace alternative

Some apps you keep. The Marketplace is full of excellent vendors, and rebuilding a deep tool for the sake of saving money is a bad trade. We say so when that is the answer.

For the ones we recommend rebuilding, the case is straightforward. A custom Forge app is scoped only to the 20% your team uses. It runs inside Atlassian Cloud, in the same security perimeter as your Jira or Confluence instance, so data never leaves your tenancy. The codebase is yours. The roadmap is yours. The pricing model is pay-once-plus-retainer, not pay-per-seat-forever.

The fit is the underrated part. Marketplace apps are designed for the average customer in their segment. Yours is designed for you. The screens have the fields you actually need. The workflows match how your team actually works. The integrations connect to your systems, not generic ones.

Marketplace apps optimize for the median customer. Custom Forge apps optimize for you.

Small team, large team, same logic, different math

The 80/20 holds at every size. The reasons to act are different.

Small teams benefit because they are price-sensitive, and every dollar that is not going to per-seat licensing is going somewhere useful. The savings compound quickly because the audit work is the same shape regardless of team size, but the spend curve is steeper for small teams as they grow.

Mid-sized teams benefit because they are paying enterprise prices for fragmented use. Different departments bought different apps for the same problem. The audit consolidates, the rebuild focuses on the consolidated need, and what used to be three line items becomes one.

Large enterprises benefit because the absolute spend is huge and the audit reveals the most savings in absolute terms. They also benefit from the security story: a Forge app sits inside Atlassian Cloud, so the compliance posture matches the rest of the Atlassian footprint without adding a third-party vendor review.

The conversation looks different at each size. The economics work at all three.

The numbers, plainly

We do not publish fabricated percentages, and we will not pretend the math is universal. Every instance is different.

What we can say is this. For a mid-sized team replacing a major Marketplace app on per-user pricing, the break-even on a custom Forge replacement typically lands between 12 and 24 months. After that, every month is savings. The app keeps working as long as you keep the small ongoing retainer for maintenance and Atlassian API tracking, and even that is a fraction of what the Marketplace bill was.

The actual numbers we put in front of you come out of your audit, not our marketing page. They are based on your seat count, your apps, your contracts.

The risks worth thinking about

What if Atlassian deprecates a Forge API the app depends on? Atlassian announces breaking changes months ahead, and the same risk applies to the Marketplace app you would be replacing. The difference is who decides whether the work gets done. With a subscription, that is the vendor’s call.

Are you replacing one lock-in with another? Only if you build it as a black box. Code you own, running on the same Atlassian Cloud you already trust, with a documented build and a named maintainer, is a very different kind of dependency from a subscription you cannot fork.

Is a smaller footprint always better? No. An app that four hundred people use daily is not a cost problem, it is a load-bearing wall. The point of the audit is to tell those apart, not to get the number down.

Where to start

Start with the inventory, not the decision.

Two of our own apps exist because we kept doing parts of this by hand. Field Scout is free, and audits the custom field sprawl that tends to arrive alongside an over-large app footprint: what is active, what is stale, and what nothing has touched in a year. OnBudget answers the other half of the question, turning the work already tracked in Jira into a number you can put next to the licence line.

A focused Forge app is not the answer for every Marketplace line on your bill. It is the answer for more of them than most teams realise. Knowing what you actually have is how you find out which.