What does a Forge app developer actually build for you?

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

Somewhere next to your Jira, there’s a spreadsheet. Maybe it holds the equipment list Jira has no way to model. Maybe someone retypes numbers out of the system next door every Monday. Maybe your process needs a step Jira has no action for, so a person does it by hand. Or maybe you’re paying for an add-on at your full user count while eight people use it. If any of that sounds familiar, that is the gap Forge app development fills. Forge is Atlassian’s own platform for apps that run inside Jira and Confluence, and a Forge developer builds the piece your setup is missing: a field type Jira doesn’t have, a screen that reads from another system, a behavior of your own that your automation rules can call. Not every gap needs one, though. The skill is telling a real gap from a requirement that was only phrased like one.

How much of this can you solve without writing code?

More than most teams try before they call a developer. Jira’s configuration layer is deeper than its reputation: custom fields with different options per project and issue type, workflow validators that block a transition until the data is right, JSM request forms that show and hide questions based on earlier answers, and automation rules moving work between all of it. One quick test: give your requirement to ChatGPT or Gemini and ask how it’s configured in Jira. If you can follow the flow it describes, you’re good to go. That’s an admin’s afternoon, not a development project.

If you are still unsure after that, reach out and we will look at it with you. Part of the job is talking you out of the requirements that don’t need a developer, so the budget lands on the one that does. What’s left after that is narrower and more interesting: the problems specific to how your business works.

When does a requirement actually need custom code?

When the capability doesn’t exist at any layer. Some requirements aren’t something configuration could ever reach. They need a thing Jira has no concept of. A field whose options depend on what was picked in another field. A value that lives in a system Jira has never heard of. Or it’s a behavior nothing in Jira can express: something that has to happen on a transition, on a schedule, or against another system. Forge is open-ended about what it can add. A new kind of field, which your admins then create and manage like any other custom field. A screen of your own. Code that runs on a Jira event or on a schedule. An action your automation rules can call. From Jira’s side it all behaves like native configuration, because it is. What the platform asks in return is that the work fits its shape: anything long-running has to be built to run in pieces rather than in one pass. That is a decision your developer makes at the start, so it shapes the design instead of surprising you later.

Sometimes the app exists, and the licensing is the problem. Marketplace apps are licensed to your whole instance, not to the people using them: an app "will only function if its license matches or exceeds the tier of the host product – even if only some of your licensed users need to use the app" (Atlassian licensing). So a 900-user Jira pays 900-user pricing for a feature eight people open, every renewal, forever. A private app carries no per-user licence at all. The developer is billed for platform usage, and each app gets a free monthly allowance first (Forge pricing). It’s a real saving, with a real limit: it holds when you need one slice of a big app, not when you’d be rebuilding a mature product in full.

A good app is the smallest piece that was missing. Once the capability exists, the rest of the process belongs back in native rules. A well-built app hands its action to Jira’s automation rule builder, so your admins can call it from a rule like any built-in step. Your branching, reminders and escalations stay in Jira and JSM automation, where they can change them without you. An app that swallows the whole process is one nobody can adjust without calling the developer. That is usually what has gone wrong when an app gets rebuilt a couple of years in: it was given too much of the process to own.

Should you configure it, buy it, or build it?

Three routes close the same gap, and which one fits depends on what is actually missing:

Read the middle column carefully if you are comparing on price alone, because it is the one whose cost keeps arriving. Configuration is paid once in admin time and buying is paid every renewal at your full user count, so the comparison changes shape depending on how long you expect to run the thing. Over five years a private app built for one slice of a problem is frequently the cheapest of the three, and over five months it is almost never worth it.

When is building the wrong call?

Three situations, and none of them are close. If a mature Marketplace app already covers your requirement well and your user count is modest, buy it. You would be rebuilding somebody’s multi-year product to save a licence fee that was never the real cost. If the requirement is still moving, wait, because code written against an undecided process gets thrown away. And if nobody internally can say who owns the app after launch, solve that before commissioning it, not after.

There is a fourth case worth naming because it comes up most often: the requirement that was only phrased like development. Someone describes what they want in the language of a feature, and underneath it is a custom field and a validator. Talking those out of the scope is part of the job, and a developer who never does it is not being helpful.

What does a delivered Forge app look like?

Four apps so far, each one a gap nothing else covered: dependent fields, a field that holds a group of users, a field that pulls equipment data from the system that owns it, and the one built for German audit firms. That last one is the clearest case of a capability that existed at no layer. Auditors receive a client’s accounting data as a GDPdU export from DATEV, the standard German format for handing accounting records to an auditor. It is complete and correct. It is also close to unreadable: answering a single question about it meant loading the files into a separate verification tool and running complex queries. The app moves that question into Jira, into the engagement the auditor is already working in: they ask in plain language and get an answer against that client’s own export. Audit work sets the bar for what happens to the data. It is kept private, is not trained upon, and stays strictly in Germany, with every component of the application pinned to Frankfurt (data residency).

Frequently asked questions

If there’s a spreadsheet doing the job Jira should be doing, let’s look at it. A free discovery call will tell you whether it’s configuration, a Marketplace app, or something that has to be built — hello@viter.io.