Jira Automation Conflict Preflight

A worked example of the Kill Test. This memo is exactly what the method produces when you run it on a real idea — including the moment it dies. Five of seven tests pass. The idea is real, the pain is real, the product is buildable. Read section 7 to see why none of that matters.

§ 1The opportunity

Jira admins automate their workflows with automation rules — triggers, conditions, and actions that fire on issue events. On busy sites, rules interact: a transition fired by rule A triggers rule B, which edits a field that re-triggers rule A. The proposed product is a static analyzer that inspects all automation rules on a site and flags conflicts before they fire:

• circular triggers and runaway loops (which also burn the site's monthly execution limits)
• racing or conflicting transitions on the same issue
• edit-after-delete and stale-reference behavior
• implicit rule-ordering assumptions that break when a colleague edits one rule

Think “ESLint for Jira automation,” sold as a self-serve Atlassian Marketplace app that checks rules on every save.

§ 2Why it looks attractive

• The pain is documented, not imagined. Atlassian's own community forums carry years of threads about automation loops, throttled executions, and rules silently breaking each other. Fact [E5]
• The analysis is deterministic. Rules are structured data; conflict detection is graph analysis over triggers, conditions, and actions. No ML, no heuristics that need babysitting. Fact
• Distribution appears built-in. The Atlassian Marketplace offers checkout, fulfillment, and discovery to exactly the buyer who has this problem. Hypothesis [E7]
• It fits a solo founder. No per-customer configuration, no enterprise sales motion, low support surface if the analyzer is precise. Estimate [E8]

This is the profile that gets built on a long weekend. Which is exactly why it deserves a kill test first.

§ 3Buyer & workflow

The buyer is a Jira admin or team lead at a 50–500 seat company — someone who owns dozens to hundreds of rules, edits them weekly, and gets paged when automation misbehaves. Their current failure mode: a colleague edits one rule, an interaction goes live untested, and the damage surfaces days later as a half-broken workflow or a blown execution budget. The product slots into the moment of rule creation and editing — preflight on save, plus a site-wide audit.

§ 4Incumbent coverage

How much of this job do paid products already solve?

Estimated incumbent coverage of the preflight analysis job: 30–40% Estimate [E3] — mostly the “detect after the fact” half. The proactive half of the job appears genuinely unserved. T2: PASS.

§ 5Remaining paid white space

Apply the white-space criteria to what's left after incumbent coverage:

• Frequent? Yes — rules change weekly on active sites.
• Costly? Yes — silent workflow breakage and burned execution limits have direct operational cost.
• Standardized? Yes — the same rule schema across every Jira Cloud site; no per-customer forks.
• Reachable? Plausibly — the Marketplace puts the product where the buyer already shops. Hypothesis
• Standalone-valuable? Plausibly — “don't break production workflows” is a budget line admins recognize. Hypothesis [E4]

T3: PASS — conditional on the hypotheses above, which is normal at this stage.

§ 6Technical feasibility

Automation rules are structured JSON: components with triggers, conditions, branches, and actions. Conflict detection reduces to building a graph — which rules can fire which triggers, which fields they touch — and analyzing it for cycles, races, and ordering dependencies. Deterministic, unit-testable, and well inside one developer's capability. T–feasibility: PASS.

Note what just happened: the idea now passes demand, coverage, white space, and feasibility. At this point most builders open the editor. The next test is the one nobody runs.

§ 7Commercial API reality

The analyzer's entire value depends on one capability: reading a site's automation rule definitions through the product's own architecture.

Atlassian does provide an Automation Rule Management REST API, and it is generally available — you can list rule summaries and fetch full rule details. Fact [E1] So far, so good. Then the documentation states, on every relevant endpoint:

Forge and OAuth 2.0 are precisely the architectures a self-serve Marketplace app must use. The data the product needs to read is walled off from the only architecture that delivers marketplace-native install, checkout, and trust. The API exists. It is not commercially accessible to this product. T5: FAIL — fatal.

§ 8The fatal assumption

Cost of discovering this with a kill test: about two hours. Estimate Cost of discovering it the usual way: a built product whose install flow cannot legally reach its own input data — typically three or more weeks in.

§ 9Alternatives considered

Before writing KILL, the method requires testing whether any fallback architecture rescues the opportunity.

Each fallback survives technically and dies commercially. That pattern — “possible, but no longer the same business” — is the signature of a true fatal flag.

§ 10Verdict

§ 11Evidence ledger

Every load-bearing claim in this memo, classified and sourced. This is the standard the Kill Test holds you to on your own idea — chat-generated plausibility doesn't make it into the ledger.