I killed a SaaS idea last week after about two hours of research. The thing that killed it is one sentence in Atlassian's API documentation, and the general shape of that failure seems more useful than the idea was.
The idea
Jira automation rules fail in ways that are hard to see before they hurt: two rules firing on the same transition and racing, a rule editing an issue another rule just deleted, circular triggers, behaviour that silently depends on rule ordering. Teams hit this and debug it by hand, after the fact.
A static analyzer for automation rules looked tractable. Rules are structured data rather than free text, so the analysis is deterministic — no model guessing at intent. Atlassian has a marketplace, so distribution is at least partly solved. I have built smaller things on thinner reasoning than that.
The check
Before writing any code I try to answer one question: can the architecture I actually intend to ship reach the data it needs — commercially, not just technically?
For a Marketplace app, "install it and it works" means Forge, or an OAuth2 integration. That is the entire product experience. So the question becomes narrow and checkable: can a Forge app read automation rule definitions?
Every endpoint in the Automation REST API's rule-management group carries the same line:
Forge and OAuth2 apps cannot access this REST resource.
Eight endpoints, same sentence on each. (Verified 2026-08-13. If you are reading this later, check it again rather than trusting me — this is exactly the kind of fact a vendor changes without telling anyone.)
Why that is fatal rather than annoying
There are workarounds. A user can export rules as JSON and upload them. An API token scoped to a user's own account can read them. A local CLI could do it on their machine.
Each of those is technically fine and commercially different. They replace "install it from the marketplace and see your problems" with "read these setup instructions, produce a file, then upload it". For a low-touch self-serve product sold to teams who are already annoyed, that is not a smaller version of the product. It is a different product, with worse economics and worse conversion at exactly the moment a new user decides whether to care.
The problem is real. The analyzer is buildable. The business I wanted is not available.
The general form
"There is an API" and "my architecture can commercially use that API" are different claims, and only the second one decides whether you have a product.
Worth checking before you write code, roughly in the order these things kill projects:
- Is commercial use permitted at all, or is the API for internal and personal use?
- Does your intended auth model — Forge, OAuth2, API token, service account — reach the exact objects you need? Not the API in general. The specific resource.
- Is there a partner agreement, certification, or security review standing between you and production?
- Do the rate limits fit your access pattern, or do they fit a dashboard that refreshes once an hour?
- If the platform absorbs this capability in 12 months, what is left of your product?
None of this is exotic, and all of it is in public documentation. It just requires reading the docs for the thing that would kill you rather than the docs for the thing you want to build.
Why I bother
AI-assisted coding made building cheap enough that building is no longer the expensive mistake. Choosing what to build is. A weekend prototype costs a weekend; the wrong choice costs a month, and you find out at the end of it.
So I run a fixed set of checks before starting. This one — commercial API reality — has killed more of my ideas than any other, and it is the one that generic "validate your idea" advice never mentions, because it does not look like a market question. It looks like a documentation question, right up until it ends the project.
I wrote the whole thing up as a memo: the seven checks I run, which passed, which failed, and the sources with dates.
Memo No. 001 — Jira Automation Conflict Preflight, verdict: kill
Disclosure so nobody feels ambushed: that page also sells the method as a $49 product. The memo itself is the complete worked example and costs nothing — if you only want the seven questions and the reasoning, they are all in there.
What is the check you wish you had run before building something?
Top comments (0)