# Brief 7ac: "distribution first" week + reply desk, reviewed against X rules, market and unit economics

Date: 2026-09-04. Researcher stance: skeptical. Budget 35 web calls, 34 used. Some official X pages (devcommunity announcement, pay-per-use docs page, user-timeline endpoint page) were blocked or 404 at fetch time; where a claim rests on a secondary source that quotes X, it is marked "single source".

Plan under review: @gochaberulava (467 followers, founder + an openly labelled AI agent). Phase 1: one week, max three originals/day, 10–15 specific replies/day to 5k–100k builder accounts within 30 minutes of their post; agent drafts, human or API posts. Phase 2: a "reply desk" that watches a list of accounts, surfaces posts within minutes, drafts a house-style reply, reads via the X API at $0.005/post, used by us first and maybe sold to other small accounts.

---

## 1. X rules in 2026 that touch this plan

### 1a. The rules, quoted

| Rule | Text (verbatim) | Source | Type |
|---|---|---|---|
| Automation rules, automated replies (updated April 2026) | You may send automated replies/mentions only if recipients "have requested or have clearly indicated an intent on X to be contacted by you"; "a user following your account is not on its own a sufficient indication of user intent"; "Sending automated replies to posts based on keyword searches alone is not permitted"; "Automating these actions to reach many users on an unsolicited basis is an abuse of the feature, and is not permitted." | https://help.x.com/en/rules-and-policies/x-automation | data (primary) |
| Automation rules, AI reply bots | "deployment or operation of any AI reply bot requires prior written and explicit approval from X." | https://help.x.com/en/rules-and-policies/x-automation | data (primary) |
| Developer policy | "Always get explicit consent before sending people automated replies or Direct Messages"; "Never perform bulk, aggressive, or spammy actions"; "If you're operating an API-based bot account you must clearly indicate what the account is"; "Services that perform write actions, including posting Posts ... must follow the Automation Rules." | https://docs.x.com/developer-terms/policy | data (primary) |
| Platform manipulation and spam policy (updated April 2025) | Spam = content shared "in a bulk, duplicative, irrelevant or unsolicited manner that disrupts people's experience"; prohibited: "Sending bulk, aggressive, high-volume unsolicited replies, mentions, or direct messages"; "engaging with posts aggressively or through automation to drive traffic or attention"; "repeatedly posting identical or nearly identical posts". Enforcement: "Restricting Reach" (exclusion from search, trends, timelines, downranking in replies); "For severe violations, accounts will be permanently suspended at first detection", otherwise temporary lock for a first offence. | https://help.x.com/en/rules-and-policies/platform-manipulation | data (primary) |
| API changelog, 23 Feb 2026, "summoned reply" rule | "Programmatic replies via POST /2/tweets are now only permitted when the original Post's author has summoned the replier (by @mentioning that account or quoting one of its Posts)." | https://docs.x.com/changelog | data (primary) |
| Same rule, scope | Applies to "Free, Basic, Pro, and Pay-Per-Use plans"; "Enterprise customers and Public Utility apps are exempt from this rule." Announced by Nikita Bier as "Operation Kill the bots". Original thread: https://devcommunity.x.com/t/x-api-v2-update-addressing-llm-generated-spam/257909 (fetch blocked by robots.txt; quoted via secondary) | https://piunikaweb.com/2026/02/24/x-api-blocks-automated-spam-replies/ | single source |
| Pricing of summoned replies | "Post creation at $0.015 per request and summoned Content creation (replies and quotes) at $0.010"; "Pay-Per-Use replies are permitted only when the original author mentions the replying account or quotes one of its Posts; otherwise the API request is rejected." | https://vorplabs.com/agent-tools/x-api | single source |
| April 2026 write removal | "X removed likes, follows, and quote-post writes from all self-serve API tiers in April 2026." | https://opentweet.io/blog/twitter-automation-rules-2026 | single source |

### 1b. What this means for the plan

- **"Human or the API posts" is not one option, it is two, and one is dead.** Since 23 Feb 2026, an API reply to a 5k–100k builder who has not @mentioned or quoted @gochaberulava is rejected at the endpoint on every self-serve tier including pay-per-use (https://docs.x.com/changelog). The "within 30 minutes of their post, via API" path is technically impossible unless you are Enterprise or an approved Public Utility app. Everything in phase 1 that ships a reply must go through a human in the X UI (or a browser extension acting inside the logged-in session, which is a separate ToS risk, see 3).
- **Does a human pressing Post on an agent-drafted reply count as automation?** The automation rules define the covered behaviour as automated *actions* (posts, DMs, follows) taken "through users' accounts or via applications" (https://help.x.com/en/rules-and-policies/x-automation). Nothing in the automation rules, developer policy or spam policy regulates how a post was *written*. A human reading a draft, editing it, and clicking Post in the app is a manual action under the text as it stands. This is also the reading of every 2026 tool vendor I checked ("A draft is not an action. X has no rule against thinking with a machine", https://postweavers.com/blog/ai-replies-x-ban-risk, opinion). Caveats: (i) the AI-reply-bot clause requires written approval for "deployment or operation of any AI reply bot"; a pipeline where the human is a rubber stamp at 15 replies/day in a 30-minute window starts to look like operation of a bot, and X, not you, decides; (ii) the spam policy is behavioural: "bulk, aggressive, high-volume unsolicited replies" is prohibited regardless of who typed them; (iii) the [agent] tag on posts is good hygiene under the developer policy's "clearly indicate what the account is", but it also makes the account trivially identifiable as agent-driven if anyone reports it.
- **Enforcement examples for reply-heavy small accounts.** I found no named, verifiable 2025–26 case of a specific small account suspended for 10–15 human-posted replies/day. What exists is (a) X's own enforcement text above; (b) X's DSA transparency data cited by a vendor: "accounts under visibility filtering see an 82–85.6% drop in impressions" (https://xengageai.com/blog/ghost-ban-on-x-twitter-2026, single source quoting X's Oct 2024 report); (c) vendor heuristics, not policy: "A new account with under 100 followers sending 50+ replies per day is a red flag pattern" and "under 30 replies per day for newer accounts", ghost bans lasting "3 to 14 days" (same URL, opinion); (d) the behavioural signals vendors say X scores: "Superhuman speed: replies landing seconds after a post, around the clock, with no sleep gaps", "Identical phrasing", "Perfectly regular intervals" (https://postweavers.com/blog/ai-replies-x-ban-risk, opinion). The plan's 10–15/day is under every vendor threshold; the "within 30 minutes, every time, for a week" cadence is exactly the regularity signal they warn about.

**Bottom line for 1:** Human-posted, edited, non-templated replies at 10–15/day are inside the rules as written. API-posted replies to non-summoning authors are blocked. An agent that auto-posts replies needs written X approval. Treat "the API posts" as cut.

---

## 2. Distribution before product: what the 2025–26 evidence says

### 2a. Cases

| Case | Path | Numbers | Source / type |
|---|---|---|---|
| 68 bootstrapped apps, DistributionBase dataset (May 2026) | 43 of 68 used build-in-public on X | Of the 43: 4 at $0–10k, 13 at $10k–100k, 13 at $100k–1M, 9 at $1M–10M, 1 at $10M+ (beehiiv). "every app past $1M ARR that used build in public also ran at least one other acquisition channel alongside it"; BIP is "a trust amplifier, not a direct acquisition channel" | https://www.distributionbase.com/blog/channels/x-twitter/build-in-public-results, data (vendor dataset, survivorship bias, no control group) |
| Chatbase (Yasser Elsaid) | Product first, launched via a tweet with 16 followers | "$1M ARR in 117 days, started with a tweet to 16 followers"; later $10M ARR bootstrapped. Note: launch was 2023, not 2025–26 | https://www.distributionbase.com/blog/channels/x-twitter/build-in-public-results; https://www.startuphub.ai/ai-news/startup-news/2026/chatbase-ceo-on-ai-chatbots-and-bootstrapping-growth, single source |
| Bazzly (Filip Panoski), June 2026 | No audience; product first, then Reddit outreach ("700 DMs and 100 comments") | $2.5k MRR, "100+ high-intent visitors weekly" | https://www.indiehackers.com/post/i-didnt-build-an-audience-i-built-a-system-AwMFRZ9xB1XNfUT4X8Pz, single source (self-reported) |
| Canny, Candy Japan (HN thread) | Audience/build-in-public | Canny founder: BIP "invaluable" for first users but saturated since ~2017; Candy Japan: transparency "attracted cloners". Commenter: "99% chance you're going to end up building products for other indiehackers" | https://news.ycombinator.com/item?id=41618505, opinion |

I could not find a clean 2025–26 case of "grew an X audience first by replying, then launched, with first-month revenue attributed to that audience". Every audience-first story I found in search results was either pre-2024, a course/gumroad pitch, or lacked launch numbers. That absence is itself a finding: the reply-first-then-launch playbook is heavily marketed (https://www.teract.ai/resources/twitter-strategy-indie-hackers-2026, https://aitoolslister.com/blog/how-to-grow-on-twitter-x-as-founder, both opinion) and thinly evidenced.

### 2b. What the evidence says for 467 followers and $0 revenue

- The only dataset found says X/build-in-public amplifies trust for a product that already exists and never carried anyone past $1M alone (https://www.distributionbase.com/blog/channels/x-twitter/build-in-public-results). The two concrete "no audience" cases (Chatbase, Bazzly) had a product to point at on day one.
- One week of replies cannot move 467 followers to a number that changes launch outcomes; vendor growth guides themselves frame reply-led growth in months (https://www.teract.ai/resources/grow-twitter-following-2026, opinion). A week is, however, cheap and reversible, and it produces something useful to the reply desk: a labelled dataset of which replies got responses.
- Verdict on the question: **product (or at least a thing to link to) first; run the week of replies as a low-cost side channel and as data collection for phase 2, not as the growth plan.** The evidence line: "every app past $1M ARR that used build in public also ran at least one other acquisition channel alongside it" (https://www.distributionbase.com/blog/channels/x-twitter/build-in-public-results).

---

## 3. The reply-desk market in 2026

| Tool | Price | Monitor + draft replies? | How it posts / API status |
|---|---|---|---|
| Fireply | $69–129/mo; requires verified account with 50+ followers | Yes, monitors conversations and auto-posts in the user's voice | "Independent infrastructure (not API-dependent)", i.e. not the official write API; survived Feb 2026 by not using it (https://fireply.ai/blog/best-x-reply-automation-tools-2026, vendor, single source) |
| XEngageAI | Free; $19; $39/mo | Yes, "Multiple AI suggestions per post. Personalized to your voice" | Chrome extension, "Works directly in X's interface"; human clicks post (https://xengageai.com/blog/xengageai-vs-tweet-hunter-vs-hypefury, vendor) |
| Tweet Hunter | $49; $99/mo (fireply cites $29–49, $199 enterprise) | Yes, AI writing assistant, audience CRM | API-based; after Feb 2026 "drafting only, no auto-posting to others" (https://fireply.ai/blog/best-x-reply-automation-tools-2026; https://xengageai.com/blog/xengageai-vs-tweet-hunter-vs-hypefury) |
| Hypefury | Free limited; $19; $49/mo | No AI reply feature; engagement is via Chrome extension | "Affected (limited to user's own posts)" (same two sources) |
| Typefully | ~$12.50/mo+ | No reply automation | Scheduling/writing only (https://fireply.ai/blog/best-x-reply-automation-tools-2026) |
| Postwise | ~$37/mo+ | No reply automation | Scheduling (same) |
| XreplyAI, Bisonary | "Varies" | Draft-only, "human-reviewed" | Assisted only (same) |

Observations:
- The market already exists and is crowded at the $19–49/mo point; the feature you describe (watch list, surface fast, draft in house style, human posts) is exactly XEngageAI's and Tweet Hunter's post-Feb-2026 positioning. It is a **feature**, and the incumbents have already been forced into the human-in-the-loop shape by the summoned rule ("API-based reply automation stopped working in February 2026", https://fireply.ai/blog/best-x-reply-automation-tools-2026).
- No source gives user counts for any tool; none gives churn or willingness to pay for accounts under 1k followers. "Small accounts pay for them" is unverified. Fireply's 50-follower floor and $69 price suggest its buyers are not 467-follower accounts.
- The tools that still *auto-post* do so by not using the official API (extensions or "independent infrastructure"), which is the automation-rules and scraping-rule risk zone ("Crawling X to extract tweets ... without using the official API is against the terms", https://opentweet.io/blog/twitter-automation-rules-2026).
- Cost to run: reads are the only hard cost (see 4); LLM drafting at 100 posts/day is cents. The expensive part is the polling design, not the model.

---

## 4. Unit economics of monitoring 20 accounts

### 4a. Prices (official and secondary)

- Pay-per-use launched 6 Feb 2026: "$0.005/Post Read, $0.01/User Read" (https://docs.x.com/changelog, data).
- 16 Apr 2026: "Owned Reads" at "$0.001 per resource (1,000 for $1)"; post creation "$0.015 per post", URL-containing posts "$0.20 per Post" (https://docs.x.com/changelog, data). Owned reads apply only when "the authenticated user must own the developer app", i.e. your own posts, not the 20 watched accounts (https://tweetstream.io/blog/twitter-api-pricing, single source).
- Monthly cap on pay-per-use reads: docs.x.com says 2M/month, developer.x.com advertises none (https://vorplabs.com/agent-tools/x-api); Blotato says 3M (https://www.blotato.com/blog/twitter-api-pricing). Conflicting; irrelevant at this scale.
- Basic ($200/mo) migrated to pay-per-use after 1 June 2026; Pro ($5,000/mo) auto-migrated after 1 Sep 2026 (https://www.blotato.com/blog/twitter-api-pricing, single source). So pay-per-use is now the only self-serve path.

### 4b. The cost arithmetic

| Scenario | Reads/month | Cost/month |
|---|---|---|
| Only new posts billed (since_id polling, 20 accts x 5 posts x 30 days) | 3,000 | $15 |
| Same, plus replies/quotes the watched accounts make (realistic 15–25 items/day per active builder) | 9,000–15,000 | $45–75 |
| Naive polling, no since_id, 5 posts returned per call, every 5 min | 20 x 288 x 5 x 30 = 864,000 | $4,320 |
| Naive polling every 2 min (the "within minutes" promise) | 2,160,000 | $10,800 and over the 2M cap |

Plus one-off user lookups: 20 x $0.01 = $0.20. The $0.005 figure is right; the claim "cheap to monitor" is only true if billing is per *returned* post and you poll with since_id so empty polls return nothing. Whether an empty response is billed at all is not stated in any source I could reach (the pay-per-use docs page returned 404: https://docs.x.com/x-api/getting-started/pay-per-use). Test this with one account for a day before building.

### 4c. Can pay-per-use poll often enough? (the real blocker)

- The rate-limit page I could fetch shows GET /2/users/:id/tweets at "Per App: 10,000/15min | Per User: 900/15min" and search/recent at "Per App: 450/15min | Per User: 300/15min", but with no tier label and no pay-per-use row (https://docs.x.com/x-api/fundamentals/rate-limits). These look like Pro/Enterprise numbers. Postproxy's tier table shows Basic at 3,500/15min for lookup and 450/15min for recent search, and explicitly "provides no separate rate-limit table for pay-per-use users" (https://postproxy.dev/blog/x-api-pricing-2026/). TweetStream says "the username-timeline endpoint caps at 1,500 requests per 15 minutes per app" (https://tweetstream.io/blog/twitter-api-pricing, single source). Blotato: "Per-endpoint rate limits apply across 15-minute and 24-hour windows, with HTTP 429 responses triggered before hitting spending caps" (https://www.blotato.com/blog/twitter-api-pricing).
- **Not verified:** the pay-per-use per-15-minute limit on the user-timeline endpoint. Under the old Basic tier this endpoint was among the tightest limits (single-digit requests per 15 minutes per app in 2024–25 docs, from memory, not re-verified today). If pay-per-use inherited Basic-style limits, 20 accounts can be polled roughly once every 30–45 minutes each, which kills "surfaces their posts within minutes". If it inherited the 1,500/15min figure, polling 20 accounts every 2 minutes (150 calls/15 min) is fine.
- Workaround worth testing: one search/recent call with `from:a OR from:b ...` for all 20 handles (query length permitting) every 2–3 minutes; at 450/15min per app that is comfortably inside limits and bills only returned posts. Filtered stream would be ideal but its availability on pay-per-use is not documented in any source reached.

---

## 5. Verdicts

| Item | Verdict | Evidence line |
|---|---|---|
| Phase 1: three originals/day, one week | Keep | Nothing in the rules touches originals; the [agent] tag satisfies "clearly indicate what the account is" (https://docs.x.com/developer-terms/policy) |
| Phase 1: 10–15 replies/day, human posts, agent drafts | Change | Legal as written (automation rules regulate actions, not drafting, https://help.x.com/en/rules-and-policies/x-automation); but "within 30 minutes, every time" is the regularity signal vendors warn about, and the week will not move 467 followers (https://www.distributionbase.com/blog/channels/x-twitter/build-in-public-results) |
| Phase 1: "or the API posts" | Cut | Rejected at the endpoint since 23 Feb 2026 unless the author summoned you (https://docs.x.com/changelog); an auto-posting AI reply bot needs written X approval (https://help.x.com/en/rules-and-policies/x-automation) |
| Reply desk for our own use | Keep, as internal tool | Read cost is $15–75/month if since_id polling works; the human-posts shape is the only compliant one left and is what incumbents were forced into (https://fireply.ai/blog/best-x-reply-automation-tools-2026) |
| Reply desk as a product for small accounts | Cut for now | Feature, not product: XEngageAI ($19), Tweet Hunter ($49), Bisonary, XreplyAI already sell exactly this; zero evidence sub-1k accounts pay; no user counts from any vendor (https://xengageai.com/blog/xengageai-vs-tweet-hunter-vs-hypefury) |
| Unit-economics claim "$0.005/read, cheap" | Change | Right per read, wrong if polling is naive ($15 vs $4,320/month); the binding constraint is the unverified pay-per-use rate limit on user timelines, not price (https://docs.x.com/x-api/fundamentals/rate-limits; https://postproxy.dev/blog/x-api-pricing-2026/) |

### Three concrete changes to phase 1

1. Delete "or the API posts". Every reply is drafted by the agent, edited by the human (change at least one sentence, no shared openers), and posted in the X app. Log draft vs. posted diff; that diff is your future product's training data and your compliance record.
2. Replace "within 30 minutes" with "within the first 2 hours, at irregular times, and never more than 3 replies to the same account per week". Cap at 10/day, not 15, for the first week on a 467-follower account (vendor threshold "under 30 replies per day for newer accounts", https://xengageai.com/blog/ghost-ban-on-x-twitter-2026, opinion, but it is the only number anyone publishes).
3. Make the week a measurement, not a growth push: for each reply record author, follower count, minutes-after-post, whether the author replied/liked, profile visits and follows that day. Pre-register the kill criterion (for example: fewer than 2 author responses per 10 replies by day 4 means stop and ship product).

### Three concrete changes to the reply desk

1. Before writing any code, spend $1 on pay-per-use to answer two questions the docs do not: (a) is an empty since_id poll billed; (b) what is the 429 threshold on GET /2/users/:id/tweets and on search/recent for a pay-per-use app. Those two numbers decide whether "within minutes" costs $15 or $4,000 a month.
2. Build it as a search/recent poller (`from:` OR-list, since_id, every 2–3 min) rather than 20 timeline pollers; add a draft queue with a mandatory edit step and no post button that calls the API. Never add auto-post; the only auto-post routes left are extension/scraping routes that violate the developer policy.
3. Do not productise until you have four weeks of your own data showing author-response rate and follows per reply. If you do productise, the only defensible wedge against XEngageAI/Tweet Hunter is a narrow one: a watch list of named builder accounts plus the draft-vs-posted learning loop, sold to accounts that already have a product, at $19 or below. Assume a feature, priced as one.

---

## 6. Counts

- Sources checked: 32 (18 fetched and used; 3 official X pages blocked or 404: devcommunity announcement thread, docs.x.com pay-per-use page, docs.x.com user-timeline endpoint page; 11 seen in search results only and not relied on).
- Sources used, by URL: help.x.com/x-automation; help.x.com/platform-manipulation; docs.x.com/changelog; docs.x.com/developer-terms/policy; docs.x.com/x-api/fundamentals/rate-limits; piunikaweb.com; vorplabs.com; tweetstream.io; blotato.com; postproxy.dev; postweavers.com; opentweet.io (automation rules); xengageai.com (ghost ban); xengageai.com (comparison); fireply.ai; distributionbase.com; indiehackers.com (Bazzly); news.ycombinator.com/item?id=41618505.
- Claims by type: data (primary policy text, official changelog, or a dataset) 14; single source (one secondary page quoting X, or a self-reported founder number) 12; opinion (vendor heuristics, HN commenters, growth guides) 9.
- Key unverified items: pay-per-use rate limit on user-timeline endpoint; whether empty polls are billed; any named enforcement case against a small account for human-posted reply volume; any 2025–26 audience-first-then-launch case with revenue numbers.