The Atlassian App Paradox (Partner Edition): We sell “outcomes”… but we inherit the complexity

[#1]

If you’re an Atlassian partner (or you work closely with partners), you’ve probably felt this tension:

Customers want faster delivery, cleaner processes, better reporting, stronger governance  and they want it yesterday.
Atlassian keeps shipping powerful new capabilities  plus a Marketplace that can fill almost any gap.
So we build solutions that actually work.

And then… we also inherit the complexity of keeping that solution stable, supportable, and explainable for the next 2–3 years.

That’s the partner paradox: we get paid for outcomes, but we’re held accountable for the long tail of configuration + app sprawl.

Why the “simple Jira” pitch is getting harder

Atlassian Cloud isn’t “one product” anymore. It’s a platform: Jira, JSM, Confluence, Assets, Automation, Analytics, Guard, AI features, and more — each with its own admin surfaces, plan differences, and rollout behavior.

None of that is bad. But it changes the partner job:

• More choices means more decision fatigue

• More integration points means more failure modes

• More plan-based features means more gotchas during rollout

• More “platform” means more governance and security conversations

The part customers don’t see: every app adds an operational tax

Partners don’t just install apps. We take responsibility for:

• app selection and vendor due diligence

• data residency / compliance / security reviews

• permission models and scopes

• change management and enablement

• upgrade cadence and compatibility

• incident troubleshooting (“is it Jira, the app, or the network?”)

• and eventually… renewal conversations where the customer asks,
  “Why are we paying for 12 apps just to do basic work?”

This is why “just add an app” isn’t a lightweight answer anymore.

The risk pattern I see most often: apps solving symptoms, not root causes

A team hits friction, and the quickest fix is an app. Totally understandable. But if we don’t slow down and ask “why”, the instance becomes a patchwork.

Examples:

• reporting pain caused by inconsistent fields → bought reporting app → dashboards still wrong

• workflow pain caused by unclear process → bought workflow app → process still unclear

• knowledge sprawl in Confluence → bought navigation app → content ownership still missing

Apps can be the right solution, but only when the root problem is a platform gap, not a process gap.

A partner-friendly way to decide: “Platform gap” vs “process gap”

This is the framework I use now:

If it’s a platform gap, an app is justified.
Example: documentation lifecycle/publishing (versions, variants, releases, publishing pipelines). That’s why tools like Scroll exist, they solve something Confluence doesn’t natively do at that level.

If it’s a process gap, fix the process first.
Example: people don’t update status, stories are too big, fields aren’t consistent, no app will fix that long-term.

The other reality: App sprawl becomes vendor management

At scale, Marketplace becomes supplier management:

• vendor risk assessments

• access and data handling questions

• contractual terms

• renewal planning

• ownership when champions leave

• “who supports this when it breaks?”

And partners often become the de-facto “app platform team”, even if that wasn’t the original engagement.

Question for App Central (partner angle)

What’s your biggest pain right now?

• customers asking for fewer apps (cost pressure)?

• security teams blocking apps (trust pressure)?

• maintaining solutions across constant Cloud change?

• renewals and vendor management?

And what’s your rule of thumb for when you say:

• “native is enough”

• “this is an app use case”

• or “this is a process problem, not a tool problem”?

Would love to hear the real stories, especially the ones where you simplified the stack and things got better.

[Miron Ivano _Worklog360_]

Hi, I really like your overview aseptically the comparison “Platform gap” vs “process gap”.

We are a Atlassian app vendor that has build only one app (instead of multiple once that do small specific work). This was made on purpose  because we believe an app should only support/cover a specific business process that certain type of companies have.

Example Service companies/consultancies that use JIRA and need to track time, bill clients, stay profitable. In such cases they might need several apps from the marketplace to cover this big workflow, but we built one specifically made for them. 

Its was not a easy decision because we pushed away other type of companies potential customers. But we really wanted to provide one deep solution for those companies and that workflow. 

We haven't work with Atlassian partners till now, so I am sure how do they handle this Platform gap” vs “process gap” with their customers. 

Cheers!