The Secret Sauce of Atlassian Marketplace Apps: Why the 1% Philosophy Beats Technology

Introduction

Since 1908, British riders had only won one gold medal at the Olympic Games. The team’s performance was so disappointing that one of Europe’s top bike manufacturers refused to sell them bikes, fearing it would hurt sales if other professionals saw the Brits using their gear. British Cycling’s fortunes changed one day in 2003.

The organization hired Dave Brailsford as its new performance director. His strategy was deceptively simple: “the aggregation of marginal gains” – improve everything by 1%, and the compound effect becomes unstoppable.

Brailsford and his coaches began by making small adjustments you might expect from a professional cycling team:

• They redesigned the bike seats for more comfort.
• Rubbed alcohol on the tires to improve grip.
• Asked riders to wear electrically heated shorts to keep muscles at the right temperature.
• Used biofeedback sensors to track how each athlete responded to workouts.

But they didn’t stop there. They kept finding 1 percent improvements in overlooked and unexpected areas:

• Tested different massage gels to see which one led to the fastest muscle recovery.
• Hired a surgeon to teach riders the best way to wash their hands to reduce their chances of catching a cold.
• Determined the type of pillow and mattress that led to the best night’s sleep for each rider.
• Even painted the inside of the team truck white, which helped them spot tiny bits of dust that would normally go unnoticed but could degrade the performance of the finely tuned bikes.

The result: Five years later, they secured 60% of the Olympic gold medals in cycling at the Beijing Games. Bradley Wiggins became the first British cyclist to win the Tour de France. His teammate Chris Froome won it five more times over six years.

This principle applies directly to the development of Atlassian Marketplace solutions. The difference isn’t revolutionary technology. It’s the discipline to improve 1% every day, in every process, and in every decision.

What Is the 1% Philosophy?

The 1% philosophy, also called the “aggregation of marginal gains”, is a method of improvement where small, gradual changes add up over time to create major competitive advantages.

Key principle: Instead of looking for one big breakthrough, focus on making many small improvements in every part of your development process.

For Atlassian Marketplace vendors, this means:

• Automating code quality checks instead of relying on manual review.
• Documenting code standards instead of debating formatting in PRs.
• Creating reusable components instead of copy-pasting between projects.
• Running dependency audits instead of discovering vulnerabilities in production.

Each small improvement adds up to a significant boost in development speed and product quality.

The Hidden Cost of Skipping Process Improvements

According to our internal stats from working with Atlassian Marketplace vendors:

1️⃣ Only 10% of clients had well-configured automation processes

2️⃣ Every 2nd client didn’t use code review practices

3️⃣ Almost all clients didn’t have code style documentation

These seemingly minor issues create compound losses – wasted time, wasted money, lost competitive advantage. Remember what I said about 1% improvements? They work in reverse, too. Small inefficiencies compound into significant problems.

Even Apple Gets It Wrong

You might start thinking that we worked with the wrong clients and it’s only our particular case.

I would disagree with you because the reality is a bit different. Apple released its App Store web version with source maps exposed in production.

To prevent such issues, Apple engineers needed to add only one flag that removes source maps in production. One configuration flag.

If Apple – with unlimited resources, world-class engineers, and decades of experience – can deploy source maps to production, your team can definitely benefit from process improvements.

This isn’t about skill. This isn’t about experience. This is about systems. It’s about the 1% improvements in the process that prevent such mistakes.

Real Numbers from a Production Atlassian App

Let us share real numbers from one of our clients:

• Timeline: 13 months from start to mature product.
• Team: 5 dedicated developers.
• Scale: 100+ end-to-end tests covering 20+ versions of Jira.
• Reusability: 60+ components.
• Speed: First version delivered in under 3 months.

This wasn’t luck. Each 1% improvement implemented early compounded over those 13 months. The automation we set up in week one paid dividends every single week after.

Below you can find feedback from the founder.

The Three Essential Audits

Audit 1: Dependency Checks

Review outdated packages, known vulnerabilities, and unused dependencies.

A single security vulnerability can compromise your entire application. Outdated packages may block upgrades, and unmanaged dependencies can significantly slow development.

Tools to use:

• npm audit or yarn npm audit (built into package managers)
• Dependabot (automated updates via pull requests)

Audit 2: Dead Code Detection

We have observed projects where 15-25% of the codebase is unused, resulting in unnecessary maintenance, testing, and deployment efforts.

Search for unused files, dependencies, and exports across your codebase, as linters often miss them.

Tools to use:

• Knip - explicitly designed for TypeScript and JavaScript projects

Audit 3: Code Duplication Analysis

Duplicated code requires repeating bug fixes and feature updates in multiple locations. It also makes it harder for new developers to identify the correct version and increases the risk of hidden bugs.

Identify copy-pasted code, repetitive logic that could be abstracted, and nearly identical components.

Tools to use:

• jscpd - language-agnostic, generates detailed reports, and integrates with CI/CD pipelines.

These three audits require only 30 minutes but can reveal weeks of technical debt. This initial assessment is your first 1% improvement.

Code Styles, Code Review, Pull Request Flows

Many teams conflate these three areas, but understanding their differences is essential:

• Code styles: How we write code - formatting, naming conventions, file structure.
• Code review: How we evaluate changes - logic, architecture, potential bugs, maintainability.
• Pull request flow: What happens before merge - who approves, what tests run, how we deploy.

Each one has a different purpose. Each requires different tools. Let’s break them down.

Code Styles

The Problem

Developer A adds trailing commas at the end of arrays. Developer B dislikes trailing commas and removes them. Code review turns into a 30-minute debate over personal preference. Both developers are technically right. Both are wasting time. The business loses.

The Solution

Written code style documentation - a living document that defines:

• How we format code (tabs vs spaces, line length, quote style).
• How we name things (variables, functions, components).
• How we structure files (import order, export patterns).
• How we handle edge cases.

Additionally, implement automated enforcement:

• ESLint for code quality rules.
• Prettier for formatting.
• Pre-commit hooks that reject improperly formatted code.

The Business Impact

• Reduces review time by 20-40%.
• Eliminates bike-shedding - arguments about trivial preferences.
• New developers onboard faster because there’s one correct way.
• Zero debate during review - the linter is the arbiter.

The 1% Improvement

Document your current practices. You probably already have unspoken standards. Write them down. That’s it. That’s your first 1%.

Code Review

The Problem

Many teams overlook code review entirely. They merge directly into main because “we’re moving fast“ or “we trust our developers“. Others do code reviews inconsistently - sometimes thorough, sometimes rushed.

Both practices pose risks. Both generate technical debt. Both ultimately slow you down.

The Solution

Establish code review practices. If unsure where to start, adopt proven approaches from other teams as an initial step.

What to review:

• Logic correctness - does this actually solve the problem?
• Security implications - are we exposing data or creating vulnerabilities?
• Performance impact - will this scale?
• Maintainability - will someone understand this in 6 months?

What not to review:

• Formatting - that’s what linters are for.
• Personal style preferences - that’s what documentation is for.
• Trivial syntax choices - automate these decisions.

Who reviews:

• At least one senior developer.
• Never only the author - fresh eyes catch bugs.
• Rotate reviewers to spread knowledge.

When to review:

• Before merge, not after deploy.
• Within 24 hours of PR creation (don’t let them go stale).
• Block merge until approval (enforced by branch protection).

The Business Impact

• Reduces review time by 30-40%.
• New developers onboard faster because there’s one correct way.
• No questions about the right way to review.

The 1% Improvement

Create a code review checklist of 5-10 items and include it in your pull request template. Consistent criteria for all reviewers is your first 1% improvement.

Pull Requests

The Problem

All team members review pull requests. Each member can add comments, approve, or decline changes. No one has a clear understanding of the process.

The Solution

Define your pull request workflow by addressing the following questions:

• Who can merge PRs?
• How many approvals are required?
• What automated checks must pass?
• What’s the maximum PR size?

The Business Impact

• Reduces review time by 25-35%.
• New developers onboard faster because there’s one correct way.
• Improves time efficiency.

The 1% Improvement

• Document your PR flow.
• Add branch protection rules.
• Set up automated PR templates with checklists.
• Review and adjust the process quarterly.

Automation Tools

Every practice we mentioned can be automated. If it’s manual, it will eventually fail. Humans are inconsistent. Humans forget. Humans have bad days.

Machines are not. Machines don’t forget. Machines don’t have bad days.

As a technical leader, your role is to design systems that automatically uphold standards, rather than enforcing them manually.

Most of these tools are free, require a one-time setup, and provide ongoing benefits.

Early detection of security vulnerabilities saves weeks of incident response. Identifying build failures in CI prevents hours of production debugging. Automated comments save time on every pull request.

Component Strategy

One client had components scattered across multiple projects. Changing a button’s font size meant locating all files where that button was used, updating the styles in each one, repeating the process for every instance, doing manual testing on all pages, and hoping nothing was overlooked.

A lot of time was spent on a single simple change.

After several months of collaboration, our team implemented a component-based approach.

Here are some results:

• 60% reduction in code duplication across three separate apps.
• 60+ reusable components with modern accessibility support, internationalization, and full customization.
• Stopped using Jira/Confluence environment for local development - much faster iteration.
• Three apps (Jira + Confluence) using one shared component library.

Tools we used for such a transformation:

• Storybook - developed components in isolation.
• Mocked REST requests so we didn’t need Jira/Confluence running locally
• Chromatic - review components for non-tech people
• bit.dev - versioning for components (like npm packages)

The 1% Improvement

Extract one component. Just one. Make it reusable. Use it in two places. Next week, do another. In 3-6 months, you’ll have a library.

Resources and Inspiration

You don’t have to go through this all by yourself! Why not lean on the wisdom of those who have been there before? You can stand on the shoulders of giants - those incredible folks who have a treasure trove of knowledge just waiting to help you along the way. If we talk about Atlassian Marketplace and Forge, I would like to share the following suggestions:

• Forge Examples by Atlassian Team - Bitbucket workspace with example apps and patterns.
• Dugald Morrow - active Atlassian community member who shares practical solutions. He also has plenty of GitHub repos.
• Our Case Study - we documented our transformation in detail. Review how we built an OKR management solution for Jira and helped the team migrate from Jira Data Center to Jira Cloud.

The Compound Effect

Remember the British Cycling story? They didn’t win in 2003. They didn’t win in 2004. They didn’t even win in 2005. They won in 2008. Five years later.

For Your Business

Better processes today don’t show results today. They show results next month. Next quarter. One year from now.

• Automated checks today mean fewer production bugs next month.
• Component libraries today mean new apps in half the time, six months from now.
• Today’s code review practices aim for maintainable code that’s still readable and maintainable in 2030 or even 2050.

Why Forge Alone Won’t Save You?

We know this article is about Atlassian apps, and Forge is significant. We use Forge every day and develop Forge apps.

But here’s what nobody tells you: Forge is just the tip of the iceberg.

Everyone talks about it. Everyone focuses on it. But Forge won’t protect you from poor processes.

The secret sauce isn’t the tool - it’s the discipline behind it.

Forge and Forge CLI become powerful when they’re built on solid foundations: automation, testing, components, and reviews. These are the foundations. Forge is the cathedral you build on top.

If you want to build something sustainable, invest in practices first, technology second.

Next Steps: Pick Your First 1% Improvement

Don’t try to implement everything we discussed in this article. Don’t try to transform your entire process by Monday.

Start with 1% improvement

Pick one:

• Audit your codebase.
• Document one process.
• Automate one check.

One 1% improvement. That’s all it takes to start.
If you’re unsure where to start or how to achieve your 1% improvement, feel free to send us a message or DM on LinkedIn.