When evaluating a Jira Cloud Marketplace app, seeing that it is Built with Atlassian Forge can be reassuring.
Forge provides an Atlassian-managed platform for building and running Jira Cloud applications, and for many organizations it can simplify some of the infrastructure and security questions traditionally associated with third-party apps.
But there is an important distinction that can easily get overlooked:
“Built with Forge” does not, by itself, describe the complete architecture of an application.
That matters increasingly as organizations move from Jira Data Center to Cloud, particularly when security, data residency, regulatory requirements, or infrastructure isolation are part of the evaluation.
Forge is a platform, not a complete architecture description
Two Marketplace applications can both be built using Forge and still have materially different architectures.
A Forge application can perform its processing using Atlassian-managed Forge infrastructure.
But Forge can also support applications that communicate with remote systems.
That means the more useful question during an application evaluation isn't simply:
Is this app built with Forge?
It is:
What happens to our Jira data after the app receives it?
That leads to a much more useful set of questions.
Questions worth asking about a Marketplace app
When evaluating an application, particularly for a large or security-conscious Jira environment, I think administrators and architects should understand at least the following:
Does the application communicate with external services?
If it does, what information is transmitted and why?
Does the vendor operate its own application servers?
Some architectures require processing outside Atlassian infrastructure. Others don't.
Does the vendor maintain an external database containing customer data?
If information is persisted outside Jira, organizations may need to understand where it is stored, how long it is retained, and how it is protected.
Does Jira data leave Atlassian-managed infrastructure?
This can be particularly important during security and compliance reviews.
What OAuth scopes does the application require?
The question isn't simply how many scopes exist. The important question is whether the permissions requested are appropriate for what the application actually does.
What happens when the application is uninstalled?
Understanding where application data resides also makes it easier to understand what remains after an app is removed.
These aren't necessarily reasons to reject an application with external infrastructure.
There are perfectly legitimate reasons for an application to communicate with external systems.
The point is that the architecture should be understood rather than inferred from the Forge label alone.
The architecture we've chosen at Simitech
When developing our Jira applications, we made a deliberate architectural choice to keep things straightforward.
Our current Jira Marketplace applications are:
Built entirely on Atlassian Forge.
We don't operate external Simitech application servers for them.
We don't maintain external Simitech databases containing customer Jira data.
Customer Jira data processed by the applications does not leave Atlassian-managed infrastructure.
This wasn't simply a marketing decision.
It reduces the number of moving parts we need to operate, but it also makes the architecture easier to explain when an administrator, Solution Architect, security team, or Solution Partner asks:
Where does the customer's Jira data go?
The answer is intentionally uncomplicated.
Why this becomes more important for Government Cloud and Isolated Cloud
Architecture questions become particularly visible when organizations evaluate applications for Atlassian Government Cloud or Atlassian Isolated Cloud.
Application availability for those environments does not remove the need for an organization's own security and compliance evaluation.
In fact, it can make understanding the architecture even more important.
Security teams may want to understand external connections, data processing, storage, permissions, and vendor-operated infrastructure before approving an application.
An architecture that can be described clearly makes that evaluation easier.
But this isn't only a government-cloud issue.
The same questions can matter to banks, insurance companies, healthcare organizations, large enterprises, and any organization with strict internal security requirements.
Architecture also matters at scale
There is another side to application architecture that receives less attention: performance.
Avoiding external infrastructure doesn't mean that an application can ignore scale.
An application analyzing a few thousand Jira issues has a very different workload from one analyzing hundreds of thousands or more than a million.
For our issue-analysis applications, we've tested against Jira environments containing approximately 1.5 million issues.
For historical Jira Assets analysis, we've tested with approximately 200,000 Assets.
Working at that scale has required us to think carefully about how data is retrieved and processed, pagination, parallel requests, Jira API usage, and rate limiting.
In other words, architecture isn't only about answering:
Where is my data?
It also has to answer:
How does the application process large amounts of data without unnecessarily moving that data somewhere else?
A useful distinction during Marketplace evaluation
Marketplace applications solve very different problems, so there is no single architecture that is appropriate for every app.
Some applications genuinely need external services.
Some need to integrate Jira with systems outside Atlassian.
Some may need infrastructure that Forge alone doesn't provide.
Others don't.
What I think is important is that Jira administrators and architects know which model they are evaluating.
So when I see Built with Forge, I treat that as useful information — but not as the end of the architectural evaluation.
The next question is the more interesting one:
Built with Forge — and what happens after that?
You can see the Simitech Jira apps available on the Atlassian Marketplace here: Simitech Marketplace apps.