Atlassian Plugin Development Services

Atlassian plugins: extending Jira and Confluence

Jira and Confluence are central to how many teams plan and document work, and their built-in automation covers a lot. When it is not enough — custom fields with business logic, integrations with internal systems, specialised reports or new types of content — an app fills the gap.

Atlassian’s cloud products are extended mainly through Forge, Atlassian’s own app platform, which hosts app code on Atlassian infrastructure. Older Connect apps are being moved towards Forge, and Data Center products still use Java-based plugins. We build for each and help teams migrate between them.

Problems we solve

• Automation rules that have grown too complex to maintain
• Manual copying between Jira and other business systems
• Reports that require exporting issues to spreadsheets
• A Connect app that needs a migration plan to Forge
• A Data Center plugin that must be rebuilt for cloud

What’s included

How we build Atlassian apps

1. Requirements1 week

   Which products, users and permissions; private app or Marketplace listing.

2. Design1–2 weeks

   Where the app appears in Jira or Confluence, data model and external calls.

3. Build on Forge3–8 weeks

   Modules, resolvers, storage and UI, with tests in a development site.

4. Security & review1–3 weeks

   Scopes, egress permissions and Marketplace security requirements.

5. Release & supportOngoing

   Versioned deployments, monitoring and customer support processes.

Selling on the Atlassian Marketplace

Publishing on the Marketplace gives access to Atlassian’s customer base, but it is a product business: buyers expect documentation, support, security commitments and regular updates. Apps that run entirely on Forge without sending data outside Atlassian can qualify for the “Runs on Atlassian” programme, which many security-conscious buyers look for.

• Licensing and pricing configured through the Marketplace
• Privacy policy, security self-assessment and vulnerability reporting process
• Documentation, onboarding and in-app help
• A support channel with clear response times
• A plan for keeping up with Atlassian platform changes and deprecations

Timeline and budget

Typical ranges to help you plan. Your written estimate comes after a free discovery call.

Before you commission a Jira app

It is worth checking a few things first, because the cheapest app is the one you do not need to build:

• Can Jira Automation or Confluence templates already do this with reasonable effort?
• Is there a well-maintained Marketplace app that covers most of the need at a fair price?
• Does the app need to send data outside Atlassian, and is that acceptable to your security team?
• Who will own the app after launch and respond when Atlassian changes an API?

When a custom app is the right answer, we keep it focused on the specific workflow that existing tools cannot handle, which keeps it cheaper to build and easier to maintain.

Forge architecture in practice

Forge apps run on Atlassian-hosted infrastructure. Your code executes as serverless functions, the user interface is built with UI Kit or Custom UI, and data can be kept in Forge storage, which lives inside the Atlassian cloud. Because Atlassian hosts the runtime, there are no servers for you to patch, and many apps can qualify for Atlassian’s “Runs on Atlassian” programme, which tells customers that their data does not leave Atlassian’s environment.

The trade-off is that you work within Forge’s limits: function timeouts, storage quotas, rate limits on product APIs and a defined set of modules. Most workflow, reporting and integration apps fit comfortably. Apps that need long-running jobs or heavy processing usually split the work: Forge handles the user interface and events, while a separate service you host does the heavy lifting, called through Forge remote with explicit permission scopes.

Jira and Confluence modules we build

• Issue panels and glances — extra context on every issue, such as customer data, deployment status or approvals.
• Custom fields — calculated values, lookups from external systems and validated inputs.
• Workflow conditions, validators and post functions — enforcing process rules automatically.
• Dashboard gadgets and project pages — reporting that standard Jira reports cannot produce.
• Confluence macros and content bylines — live data embedded in documentation.
• Admin pages — configuration screens so administrators can tune the app without code changes.

Permissions, data residency and security reviews

Every Forge app declares the scopes it needs in its manifest, and administrators see those scopes when they install it. We request the smallest set of scopes the features need, because broad scopes slow down security reviews by customers’ IT teams. If the app stores personal data, we document what is stored, where and for how long, and support Atlassian’s personal data reporting so the app respects account deletion requests.

• Least-privilege scopes in the manifest
• No secrets in source code; environment variables per environment
• Input validation on every function that handles user data
• Clear data retention and deletion behaviour
• A short security and privacy summary for customers’ procurement teams

Releases, versions and support after launch

Forge separates development, staging and production environments, so changes are tested against real Jira and Confluence sites before customers see them. Minor updates roll out automatically; changes that add new permission scopes require administrators to approve an upgrade, so we group scope changes into planned major releases rather than surprising customers.

1. Develop

   Build and test against a development site with sample projects and spaces.

2. Stage

   Install the staging version on a test site that mirrors real configurations.

3. Release

   Deploy to production and monitor errors and invocation metrics in the developer console.

4. Maintain

   Track Atlassian platform changes and deprecations, and respond to customer issues within agreed times.

Pitfalls we help clients avoid

• Building a Marketplace app before confirming that teams will pay for it — a private app or a short pilot is a cheaper test.
• Designing for Jira Software only and discovering later that Jira Service Management customers need different screens.
• Loading large result sets in a single function call and hitting timeouts on big sites.
• Ignoring Data Center customers when they are the target buyers, or vice versa — the two platforms need different builds.
• Skipping documentation and in-app guidance, which drives support requests and poor reviews.

Related services

Part of our plugin & extension development services. See also enterprise integration and business process automation.

This page is part of Plugin & Extension Development Services — see the full overview for related services, approach and pricing.