AI-Generated

every day my time goes in follow up and unblocking of the tasks, use jira and lark for comms

UnblockBot 9000

ACTUALLY NOT BAD
6/10
You're a $200k engineer playing telephone between a ticket and a Slack message. Congratulations.

An agent that monitors Jira ticket states and Lark threads, identifies blockers and stale tasks, and autonomously sends follow-up nudges, escalations, and status digests so you stop playing human middleware.

The Jira + Lark pairing is genuinely underserved — most tools target Jira + Slack or Jira + Teams. The daily follow-up loop is a real, recurring pain point with measurable ROI (your time). But the graveyard of 'AI PM assistant' startups is long, mostly because adoption dies when engineers feel micromanaged by a bot.

whycantwehaveanagentforthis.com
Download card

Generates a shareable PNG image of this verdict card entirely in your browser — nothing is uploaded. Choose portrait (1080×1350, for stories and status) or landscape (1200×630, matches the link preview), then download.

Viability Analysis

Market Demand74
Tech Feasibility78
Competition65
Monetization58
AI Disruption Risk82
Fun Factor63

Pros & Cons

What's going for it

Jira + Lark is a genuinely underserved combo — most tools are built for Jira + Slack, giving you a real wedge with ByteDance-ecosystem companies
The pain is daily and quantifiable — you can literally count hours lost per week and pitch ROI to any engineering manager in under 60 seconds
Lark's open API and bot framework are surprisingly developer-friendly, making integration faster than Slack's increasingly hostile platform
Blocker detection is a narrow, solvable problem — you don't need AGI, just ticket state + time-since-update + thread silence heuristics

What's against it

Engineers will disable or ignore the bot within 2 weeks if nudges feel spammy — adoption graveyard is full of PM bots that got muted
Atlassian can ship this natively in Jira Automation rules tomorrow and charge zero extra — your moat is Lark-specific, not the core logic
Lark is dominant in Asia-Pacific but nearly invisible in US/EU markets, capping your total addressable market unless you add Slack/Teams
The 'unblocking' part requires understanding WHY something is blocked — LLMs hallucinate context and can send embarrassing follow-ups to senior engineers

Who You're Up Against

Open Source Alternatives

When Will Big AI Kill This?

Most Likely Killer

Atlassian

Timeline: 12-18 months

Now3mo6mo1yr2yrNever

How They'll Do It

Atlassian Intelligence already has Jira Automation. They add an 'AI Follow-up Agent' feature to Jira Premium, bundle it at no extra cost, and your entire value prop becomes a changelog entry

Your Survival Strategy

Go deep on Lark — build the native Lark Mini App experience Atlassian will never prioritize, and own the Southeast Asian / Chinese tech company segment completely

Confidence

72%

If You're Crazy Enough to Build It

Solo Dev Time

3-5 weeks for an MVP that actually works without embarrassing you

Team Size

1 backend dev who has actually used Jira in anger + 1 PM who has suffered through enough standups to hate them

Estimated Cost

$800-$2,500/month in infra + LLM API costs at early scale; $0 if you cap follow-up logic to rules-based before adding AI

Tech Stack

Jira REST API v3Lark Open Platform Bot APIClaude API (Haiku for cost)Node.js or Python FastAPIRedis for state/cooldown tracking

Agent-Readiness Score

Worth building, but plan for the long-tail. UnblockBot 9000 needs runway, not just speed.

57BAND C
  • Some cross-session state — start with Redis, graduate to a vector store.

  • Crowded market: at least 9 integrations to compete.

  • Wide policy surface — full red-team pass, content filter, and human-in-loop required.

  • Established eval pattern — golden datasets and public benchmarks already exist.

DETERMINISTIC SCORE — DERIVED FROM EXISTING ANALYSIS, NO SECOND LLM CALL

⚡ Ship it anyway

The version that survives

You've been dared. Here's the wedge worth your weekend — and the fastest way to find out it won't work.

01

The wedge that isn't taken

Build specifically for Lark-first companies in APAC — a native Lark Mini App with Jira sync that Atlassian will never care enough to build.

02

Test this before you write a line of code

That engineers will tolerate automated follow-up pings without muting the bot on day 3. Test this before building anything else.

03

The honest cost — and who should walk away

~4 weeks + $500 in API costs. Do NOT build this if your team is fewer than 8 people — just use n8n and a cron job.

Think the wedge holds? ↓ Pressure-test it live before you sink a weekend into it — 20 min, free, no signup.

⚡ Pressure-test the wedge

Get this wedge pressure-tested live — 20 min, free.

Bring the wedge above and we'll stress-test it together: is that differentiator really still open, does the riskiest assumption survive contact, what to build first. No signup, no slides.

Free · no signup on this site, ever. ·

How this was generated
15%UPHILL

Production-readiness odds

Real readiness gaps. Build a thin first, harden second; budget runway for both.

ANCHORED TO OUR OWN READINESS RUBRIC — NO EXTERNAL STAT CITED

🛡 Safety considerations

What these mean →

Heuristic, not exhaustive. Surfaces the 3 biggest categories an operator should think about for this idea. Hover any chip for the mitigation pointer.

⚖ Governance checklist

7 controls apply

Things to have in place before you ship. Pairs with the OWASP-style risk chips above — that catalog answers “what could go wrong?”, this one answers “what should you have ready?”

  • Audit trail of every tool call

    critical

    Persist a structured per-call log of inputs, outputs, and decisions for at least the legal retention window. Without this, post-incident review is impossible.

  • Role-based access control on the agent surface

    critical

    Different users, different scopes. The agent should never default to "admin can do everything." Pair with per-task capability scoping.

  • Tenant / workspace isolation

    critical

    A multi-tenant agent must never leak data across tenants in either direction (inputs OR cached intermediate state).

  • Secrets management

    high

    Tokens and API keys live in a vault, not in env vars on a CI runner. Rotate on a documented schedule, not "when something happens."

  • Eval coverage on every release

    high

    A frozen eval suite that runs on every model / prompt change. "It worked when I demoed it" is not a release gate.

  • Per-user / per-tenant rate limits

    medium

    Agent loops are pathologically expensive when wrong. Cap tokens-per-session, tool-calls-per-session, and dollars-per-day before launch.

  • Pin model versions; track the changelog

    medium

    A silent provider-side model upgrade can shift behavior overnight. Pin to a versioned model ID; subscribe to the provider changelog.

OUR INTERNAL TWELVE-CONTROL SYNTHESIS — STANDARD SOC 2 / ISO 27001 / GDPR FAMILIES APPLIED TO LLM AGENTS

🛠 Build this with Claude Code

Skip the boilerplate. Start from a working spec.

We've packaged this idea into a CLAUDE.md + scaffold.sh starter — the problem statement, agent-readiness sub-scores, suggested tools, and smoke evals, all deterministic and ready to drop into a fresh repo. Open it in Claude Code, or copy the markdown into any IDE.

Don't have Claude Code yet? View the bootstrap preview · grab the JSON bundle · or embed the readiness badge.

🛠 Steal this idea

Going to build UnblockBot 9000? Claim it.

Post a public 2-paragraph plan. Add the repo URL when you ship. No rights granted; no permission required — credit goes to whoever ships first. See all claims at /steal-this-idea.

0/1200

Want to actually build this?

Work with me to ship it.

Survived the verdict? Good. Let's build the damn thing.

Book a 30-min call

Got another problem that needs an agent?

Roast My Problem

whycantwehaveanagentforthis.com