What Shipping Atlassian Plugins Taught Us About Building for Other People's Platforms
Building inside someone else's ecosystem is a different discipline to building your own product. Here is what we learned the hard way.
Building a plugin for someone else's platform is a very specific kind of engineering challenge. You do not control the runtime. You do not control when breaking changes arrive. You do not control the environment your users are running in. And your users will configure things in ways you absolutely did not anticipate.
After shipping nine Forge apps to the Atlassian Marketplace, we have some opinions.
You Are Always a Guest
The single most useful mental model for platform development is that you are building inside someone else's house. The walls might move. The kitchen might get renovated. You adapt, because you do not have the option of pushing back.
This means building defensively. Assume the APIs you rely on will change. Read the deprecation notices. Do not build deeply against undocumented behaviour. The teams that treat platform constraints as temporary problems to work around are the ones that end up with breakage they did not see coming.
The Variance in Customer Environments Is Wild
Testing your plugin against a clean instance and testing it against an enterprise environment that has been configured by six different admins over five years are entirely different experiences. Enterprise Atlassian environments have custom fields, unusual permission structures, legacy workflows, and a lot of history.
The practical implication is that defensive coding is not paranoia — it is necessary. Handle the cases where a field you expect does not exist. Handle the cases where a user does not have the permissions you assumed. Degrade gracefully rather than crashing in a way that reflects badly on you.
Performance Expectations Are Strict
Users inside Jira expect Jira-level performance. Your panel loading in 800ms feels snappy in a standalone web app. Inside Jira, it feels slow. Inside Jira on a large instance, it might feel broken.
Every API call is potentially expensive. Every render matters. Optimising for performance from the start — rather than treating it as something to address later — saves a significant amount of pain during Marketplace review and after real customers start using the plugin.
The Support Load Is Underestimated
The hardest part of shipping plugins is not the initial build. It is supporting them across the long tail of customer environments and usage patterns that emerge over time. Issues appear that are impossible to reproduce because they only happen in a specific customer's configuration.
Good logging, clear in-app error messages, and a support page that anticipates common questions reduce this load dramatically. It is unglamorous work that pays consistent dividends.
Thinking about building an Atlassian plugin or expanding your existing marketplace presence? Talk to us — we can help from architecture through to submission.