Writing and content decision
Tweet.md
A capable developer can implement a useful URL-rewrite + X-API-to-Markdown tool in about a week, but reproducing production billing, anti-abuse, and polished multi-agent integrations that the paid product offers is more work and operations-heavy.
Visit website↗Not priced
No pricing page we fetched carried a figure, so there is nothing to compare against. The build side is still real.
$100one-off32 h to build
$50/mo3 h/mo upkeep
No published price to break even against.
No open-source build does this yet
Nothing published replaces this one, so a replacement starts from an empty file. Here is what it would have to cover.
What a replacement has to do
- Accept an X/Twitter URL (or API request) → fetch canonical post/thread/profile from the X API → normalise thread structure and metadata → render clean LLM-ready Markdown (optionally Obsidian frontmatter) → return to caller and deduct one or more credits from the user's balance.
What it still won’t have
- Production-grade credit/billing UX, checkout and fraud/abuse protection
- Polished documentation, agent/shortcut integrations and cross-LLM compatibility testing
- Reliability, scaling, and observability at traffic levels beyond a single user
- Any legal, compliance, or long-term API contract guarantees the vendor may manage
What remains hard
- Product polish and ongoing maintenance
First-year cost
No published price
Tweet.md does not publish a price we could read, so there is nothing to compare against. What building costs is below.
Money you would actually spend
Time you would spend
—
What you would spend
What we assumed
The verdict above measures whether you could build it. This one is only about money.
Runnable build prompt
Build a minimal tweet.md clone using Node.js (Express) + TypeScript, Postgres for accounts/credits, and Redis for short-lived sessions; deploy to a single DigitalOcean App or Vercel serverless. Core features in scope: 1) URL-rewrite HTTP handler that accepts /:handle/status/:id and maps to an internal convert API; 2) server-side X API client to fetch posts/threads/profiles (support thread=ancestors|branch|all and stats/userinfo params); 3) deterministic transformer that outputs plain Markdown and an obsidian format with YAML frontmatter; 4) simple checkout/topup flow that mints a browser session cookie and issues an API key for server use; 5) header-based Authorization and ?apikey= support; 6) demo page that runs free controlled conversions and an /i/api/convert JSON endpoint; 7) tests for transformer correctness and error handling. Out of scope: payment processor integrations beyond a test Stripe key, advanced anti-abuse (rate-limiting beyond basic IP/key buckets), UI polish, and distributed scaling. Require proper error handling, logging, and unit tests for the conversion logic and auth flows.
How we checked
How the score was reached
- Partly verdict base52
- 2 cited sources+1
- Evidence score53
The base comes from the verdict. Everything under it is a check that either happened or did not, and each one is a fact frozen in this record rather than a judgement made at render time - so the same evidence always produces the same number.
How scoring works →Cited sources · 2
Every page the run actually retrieved.
- official producttweet.md — X/Twitter to Markdown Converter
- official docstweet.md docs — X/Twitter to Markdown API documentation
Integrity checks
What held up, and what did not.
