When should I use a Forge app instead of a Jira Marketplace app?

Written by Ben Friedman, Atlassian expert & builder of JAMEs, the AI Jira administrator · Published 24 August 2026

Forge apps offer flexibility and pricing that Marketplace apps can’t compete with. Marketplace apps provide one stop shop solutions, where everything is taken care of for you.

The choice you are actually making is between a finished product with a vendor behind it and an app that exists only in your site and does exactly what you asked for. If you want the delivery side of that second option, Forge app development covers what actually gets built and how.

Each path has its clear benefits. If you are unsure which option is right for you, read on :)

Key takeaways

Forge is not the alternative to buying. Most Marketplace apps are built on it too, so the real choice is a finished product versus one that exists only in your site.
Build when the requirement is narrow. One rule, one screen, one connection to an internal system is small to write and small to keep.
A paid cloud app is billed against your Jira user tier, so the invoice follows how big your Jira is rather than how many people open the app.
Buy when you need a complete solution, not a tailored critical update. Test management, portfolio planning and deep reporting are years of accumulated work, and rebuilding one privately is starting a software company.
A private app has no other customers finding its bugs, no trial, and usually one person who understands it. Anyone selling you a build who skips that part is selling.

What is Forge?

Forge is Atlassian’s platform for building apps that run inside Jira, Confluence and Jira Service Management. The code sits on Atlassian infrastructure rather than a server of yours, the app declares up front what it is allowed to touch, and it installs into your site like anything else you would add.

What an app can do from there is wide. It can add fields, panels and whole screens inside an issue, run code when something changes, call an internal system of yours, and hold its own data. Most of what you would buy from the Marketplace is built the same way, on Forge or on Connect before it, so the platform itself is not what separates the two options.

When to choose a Forge app?

When the requirement is narrow and specific to how you work. One rule that has to hold at a particular transition. One screen showing something the standard view will not show. One connection to an internal system nobody outside your company runs. Each of those is small to write, small to keep, and never worth a subscription billed across everyone in the business.

Pricing is the second reason, and it is the one that catches people out. A paid cloud app on the Marketplace is billed against the host product’s user tier, so the invoice follows how many people hold a Jira licence rather than how many open the app. Twelve people out of five hundred using something priced against all five hundred is the most common moment a buyer starts asking about custom work. Growth in one part of the business quietly raises the price of software used entirely by another part.

You own the code, so you can extend a Forge app whenever the process moves, without waiting on a roadmap, and you are not exposed to a vendor being acquired, repricing, or going out of business. Our field security app, as an example, is a Forge app that writes to Jira configuration, and it has no Marketplace listing at all. Absence from the Marketplace says very little about an app on its own.

When to choose a Marketplace app?

When the problem is big enough to clearly require a substantive development effort and a high dependency on Atlassian APIs. Test management, portfolio and capacity planning, deep cross-project reporting, time tracking with an approval flow behind it, structured document management. Each of those is a product in its own right that happens to live inside Jira. Rebuilding one privately is not a build. It is starting a small software company.

What you are really buying is everybody else’s bug reports. A commercial app has thousands of installations exercising it in ways its authors never imagined, and every edge case found there is one you never meet. You also get a support desk staffed by people who have seen the failure modes before, and a vendor who absorbs platform changes as ordinary business because the cost is spread across everyone who pays them.

Compliance related requirements usually belong here too. When procurement or an auditor wants evidence that software has been reviewed, a vendor with published documentation and a security programme answers that question in a way a private app has to answer from scratch. A subscription can also be switched on for a month, put in front of the team and cancelled, which makes buying a reversible decision in a way that commissioning a build never is.

What you are holding	Marketplace app	Custom Forge app
A whole category of work many companies need in the same area	Buy. Years of accumulated edge cases, already tested	Effectively rebuilding a software product
One missing rule, field or screen inside a workflow you already run	Overkill, and billed against everyone licensed	Small to write and small to keep
An app twelve people out of five hundred actually open	The invoice follows your Jira tier, not the usage	Worth it when the used part is genuinely narrow
A requirement no vendor has shipped and yours needs	Request it and wait on priorities you do not set	The specification is yours
A link between Jira and an internal system nobody else runs	Nothing generic will fit it properly	The normal reason private apps get written
Nobody internally who will own it in two years	The vendor keeps it alive for you	A real risk. Someone must redeploy when the platform moves

Read your situation into the left column before comparing anything else, because the answer usually falls out of it without a feature list being involved. The first and last rows push hard toward buying and the middle four push toward building. A requirement that lands in both places is normally two requirements wearing one name, and splitting it is often the whole answer: buy the part that is a category, build the narrow piece that is specific to you.

Forge development by a 3rd party?

The golden path, when it works: software built around your process, and somebody else carrying the platform. No internal hiring, no team to keep busy once the app is finished, and no vendor roadmap standing between you and a change you need next month. The specification is yours and so is the code.

What decides whether it works is the arrangement, not the app. Three things belong in it in writing. Who redeploys when Atlassian moves the platform, and on what notice. Where the source lives, and that it belongs to you. Who can pick it up if the people who wrote it disappear. All three are cheap to agree at the start and expensive to sort out afterwards.

The rest is ordinary scoping. A narrow app is a short piece of work with a clear finish, and the specification deserves the time because it is the only genuinely irreversible part. Anyone quoting a build without asking who owns maintenance afterwards is quoting half the job.

The honest case against building

Nobody else is finding your bugs. A commercial app has thousands of installations shaking it out for free, and a private app meets its edge cases in production, in front of the people who depend on it. That is a real cost and it lands on you.

There is no trial either. A subscription goes in front of the team for a month and gets cancelled if the answer is no. Commissioning a build spends the money before anyone can use it, which raises the bar on being right about the requirement before anything starts.

Ownership is the one that catches people out most often. Atlassian moves the platform, and a private app needs somebody to notice, update it and redeploy. An app nobody has looked at in eighteen months meeting a deprecation nobody was watching for is the usual failure, not a dramatic breakage. If your requirement turns out to be a category rather than a quirk, buy the product and hire nobody.

Frequently asked questions

Are Marketplace apps not built on Forge themselves?

Many of them are, and the rest are largely on Connect, the platform Forge succeeded. Forge is how an app gets written and installed. The Marketplace is how one gets sold. Comparing them as rival technologies leads to a debate about security models where the two are broadly equivalent. The decision that matters is whether you want a finished product with a vendor behind it or software that exists only inside your own site.

Why does a Marketplace app cost more as our Jira grows, even when nobody new uses it?

Paid cloud apps are billed against the same user tier as the host product, so the figure driving the invoice is how many people hold a Jira licence rather than how many open the app. Growth in one part of the business raises the price of software used entirely by another part. Check your renewal against actual usage roughly once a year, because the gap tends to open slowly and nothing prompts you to look.

Can a Forge app be extended after it has been built?

Easily, and it is one of the better reasons to build. You hold the code, so a change to the process becomes a change to the app rather than a feature request sitting on a roadmap you do not control. It also removes a dependency most buyers never price in: a vendor can be acquired, reprice, deprecate a product or go out of business, and none of that can happen to software that exists only in your site. What replaces it is a maintenance obligation, which is a different risk rather than no risk.

What happens to a private app when Atlassian changes the platform?

Somebody has to update and redeploy it. Atlassian gives notice and the changes are usually modest, and modest still means a person needs to read the notice, make the change and test the result. Whoever built the app can hold that responsibility, and the arrangement should be written down rather than assumed. The failure mode is not a dramatic breakage. It is an app nobody has looked at in a long time meeting a deprecation nobody was watching for.

Is a private app harder to get through a security review?

Different rather than harder, and it can be considerably easier. There is no vendor questionnaire to complete because there is no vendor, and a Forge app runs inside Atlassian’s hosting with the permissions it declares, which is a shorter conversation than a third party processing your data elsewhere. What you lose is the ability to point at somebody else’s published certification, so the review examines the app and whoever maintains it instead.

How narrow does a requirement have to be before building makes sense?

A useful test is whether you can describe it in one sentence without the word "and". A rule enforced at a particular transition, a screen showing one thing the standard view will not show, a connection to an internal system nobody outside your company runs: each is a small, contained piece of software. Once the description needs several clauses joined together, you are describing a product, and somebody has probably already built it.

Describe the requirement in a paragraph and you will get a straight read on which side of this it falls, including the answer that you should buy something and hire nobody. hello@viter.io

About the author

Ben Friedman is an Atlassian consultant and Forge developer with over 8 years of hands-on Jira work, certified ACP-610, ACP-620 and ACP-120. He has delivered for hundreds of customers across all business verticals, supporting their configuration, administration, and ongoing support and maintenance. Ben is building JAMEs, the AI Jira admin.