Show original
Enjoyed this article?
Use "Request tipping" to ask the author to set up tip receiving.
Share
Keita NakagawaPublished August 5, 2026AI translation
We stopped rewriting announcement texts, introduction articles, and store screenshots with each release, and switched to an operation where we generate them from the README as the starting point. This is a measure to place "promotion," which tends to be put off last in individual development, as an extension of implementation.
Enjoyed this article?
Use "Request tipping" to ask the author to set up tip receiving.
After reaching release in personal development, I kept getting stuck at the same point every time. The implementation was done, but I couldn't write the announcement. Days would pass without writing anything, and I'd end up just throwing out a single line saying "I made it" and calling it done. The number of things I created kept growing, but nobody knew about them.
When I broke down the cause, the problem wasn't that promotion was difficult—it was that I was "rewriting the app description from scratch every time I promoted it."
X posts, note articles, App Store screenshots. The media varied, but the information was almost identical. What the app does, what becomes easier for whom, what makes it different from others. The only differences were the length and tone of the writing—the source material was all the same.
And that source material was already in my hands. The README.
Normally, a README is written as documentation for developers. But looking at the content, it actually contains most of the information needed for promotion. What the app is, what it does, how to use it, what the limitations are. The only thing missing is "the perspective that the reader isn't a developer."
So I decided to treat the README not as a memo for development, but as the primary source of information about the app. There's only one rule.
Always update the README before release.
Update the README, commit it, and push it before deploying or uploading to TestFlight. Don't reverse the order. That's all I do. If you allow "I'll fix it later," the README becomes a liar in an instant.
With this order, at the moment of release, you always have "the latest description of that app" on hand. After that, it's just a matter of translating it for each medium.
Right now, when I pass the README URL, three things come out.
The first is posts for X, with multiple patterns from different angles. The second is a draft of an article for note. The third is headline copy and layout for App Store submission screenshots.
Writing from scratch takes a full day, but just editing the generated text takes 15 minutes. Changing this "0→1" to "70→100" was what made the biggest difference.
The same approach works directly for multiple languages. If you run a Japanese announcement through machine translation, the text inevitably becomes unnatural. But if the source is a README, you can "rewrite it in that language" instead of translating.
Right now, I'm putting out X posts and App Store screenshot headlines in 8 languages: Japanese, English, Spanish, Simplified Chinese, Traditional Chinese, French, German, and Korean. These aren't translations of the Japanese version—they're written from scratch in each language from the same README. The barrier to putting out announcements for overseas markets dropped dramatically here.
Summing up what I'm doing, it comes down to this:
Update the README before release. Using the README as primary source material, generate materials for each medium. Edit the generated content and publish it.
I just replaced the part I was doing through willpower with a procedure, but promotion went from being "a special task to do later" to becoming part of the release workflow. The most wasteful situation—where what you made ends up unknown to anyone—has been significantly reduced.
I automated this flow for myself in a web app called Code Tweet. You paste a GitHub repository URL, it reads the README, and generates X posts, note article drafts, and App Store submission screenshots. No login required, and you can try it 3 times.
If you have the same problem, try just "updating the README before release" first. Even without using tools, the effort required for promotion changes significantly.
個人開発でリリースまで漕ぎ着けたあと、毎回同じところで止まっていました。実装は終わっているのに、告知文が書けない。書けないまま数日たって、結局「作りました」の一言だけ投げて終わる。作ったものは増えるのに、誰も知らないままになる。
原因を分解してみると、宣伝が難しいのではなく、宣伝のたびに「アプリの説明をゼロから書き起こしている」ことが問題でした。
Xのポスト、note の紹介記事、App Store のスクリーンショット。媒体はバラバラですが、載せている情報はほとんど同じです。何ができるアプリか、誰の何が楽になるか、他と何が違うか。書き方の長さとトーンが違うだけで、元ネタは全部同じでした。
そして、その元ネタはすでに手元にあります。README です。
README は普通、開発者向けのドキュメントとして書きます。でも中身を見ると、宣伝に必要な情報はだいたい揃っています。何のアプリか、何ができるか、どう使うか、制限は何か。足りないのは「読者が開発者ではない」という視点だけです。
そこで、READMEを開発用のメモではなく、そのアプリについての一次情報として扱うことにしました。ルールはひとつだけです。
リリースする前に、必ずREADMEを最新にする。
デプロイやTestFlightへのアップロードより先にREADMEを更新して、コミットしてpushする。順番を逆にしない。これだけを守っています。「あとで直す」を許すと、README は一瞬で嘘つきになるからです。
この順番にすると、リリース時点で「そのアプリの最新の説明」が必ず手元にある状態になります。あとはそれを媒体ごとに翻訳するだけです。
私は今、READMEのURLを渡すと次の3つが出てくる状態にしています。
ひとつめはX向けのポストで、切り口を変えて複数パターン。ふたつめはnoteに貼れる紹介記事の下書き。みっつめはApp Store提出用スクリーンショットの見出しコピーとレイアウトです。
ゼロから書くと1日仕事ですが、出てきた文章に手を入れるだけなら15分で終わります。この「ゼロ→1」を「70→100」に変えたのが、いちばん効きました。
同じ考え方は多言語にもそのまま効きます。日本語で書いた告知を機械翻訳にかけると、どうしても不自然な文章になります。でも元がREADMEなら、翻訳ではなく「その言語で書き直す」ことができます。
私は今、XのポストとApp Storeスクショの見出しを、日本語・英語・スペイン語・簡体字中国語・繁体字中国語・フランス語・ドイツ語・韓国語の8言語で出しています。日本語版を訳したものではなく、同じREADMEからそれぞれの言語で書き起こしたものです。海外向けの告知を出すハードルが、ここで一気に下がりました。
やっていることをまとめると、こうなります。
リリース前にREADMEを最新にする。READMEを一次情報として、媒体ごとの素材を生成する。生成物に手を入れて出す。
気合いでやっていた部分を手順に置き換えただけですが、宣伝が「あとでやる特別なタスク」ではなく、リリース作業の一部になりました。作ったものが誰にも知られないまま終わる、という一番もったいない状態は、これでかなり減っています。
この流れを自分用に自動化したのが、Code Tweet というWebアプリです。GitHubリポジトリのURLを貼るとREADMEを読み取って、X向けポスト・note記事の下書き・App Store提出用スクリーンショットを生成します。ログイン不要で3回まで試せます。
同じ悩みを持っている方は、まず「リリース前にREADMEを更新する」だけでも試してみてください。ツールを使わなくても、宣伝の手間はかなり変わります。