Show original
Enjoyed this article?
Support KOUSUKE
Share
KOUSUKEPublished April 25, 2026AI translation
Before creating Tsukutta, there were 2 features I was absolutely confident would resonate with individual developers. To cut to the chase, both ended up being barely used. Looking at recent data, among the published apps: Posts via MCP: 3 cases (approximately 1%) File distribution (uploading zip/exe, etc.): 3 cases (approximately...
Enjoyed this article?
Support KOUSUKE
Before building Tsukutta, there were 2 features I was absolutely convinced would resonate with individual developers.
To cut to the chase: both were barely used.
Looking at recent data, among the published apps:
The two flagship features combined don't even reach 2% of the total. I'll write about the miscalculations behind each and what I learned.
Tsukutta aims for "individual developers to release more apps into the world." So I thought being able to publish without breaking the coding flow was crucial.
Specifically, from Claude Code via MCP, you could just say "upload this project to Tsukutta" and it would automatically scan the repository, sanitize secrets, auto-detect screenshots, and publish to Tsukutta. Surely this is way more efficient than opening a UI form and manually entering data, I genuinely believed.
Actual result: 3 posts.
The reasons it didn't resonate were probably:
The other feature was zip/exe file distribution. I intended to solve the problem of people building desktop apps or iOS/Android app developers having no distribution channel. You could upload to Tsukutta and get a shareable link.
Actual result: 3 apps with file distribution.
This assumption also missed the mark:
1. "What I find convenient" and "what users actually use" are different things. The MCP server works perfectly within my own workflow. But I'm only one person out of all users.
2. Usage rate is a signal for hypothesis validation. Whether you read 1% as "it'll grow with more promotion" or "the persona I envisioned doesn't actually exist" changes your next decision. For me, it was the latter.
3. Features you invest heavily in don't necessarily resonate. The MCP server took considerable effort in design + implementation + security hardening (rate limiting/sanitization). Yet it still didn't resonate.
I'm not planning to remove either feature. If 3 people are getting value from it, it's worth maintaining.
Instead, I'm now looking at what users who posted via the form want next. Request features, articles, rankings, follow functionality ── I'm stacking one thing at a time based on data, looking for reasons that make people who came here want to use it more.
It's painful to have missed the mark, but I'm glad I could recognize these things.
Tsukuttaを作る前に、「これは個人開発者に絶対刺さる」と確信していた機能が2つあった。
結論から書くと、両方ほぼ使われなかった。
直近のデータを確認すると、公開アプリのうち:
肝いりだった2つが、合わせても全体の2%に届かない。それぞれの誤算と、何を学んだかを書いておく。
Tsukuttaは「個人開発者がもっとアプリを世に出すこと」を目指している。だからコーディングの流れを切らずに公開できるのが大事だと思った。
具体的には、Claude CodeからMCP経由で「いまのプロジェクトをTsukuttaに上げて」と指示するだけで、リポジトリのスキャン、秘密情報のサニタイズ、スクリーンショット自動検出、Tsukutta掲載まで全部走る。わざわざUIフォームを開いて入力するよりずっと効率的じゃないか、と本気で信じていた。
実際の結果: 3件。
刺さらなかった理由はおそらく
もう一つは、zip/exe等のファイル配布。個人開発でデスクトップアプリを作る人や、IOSやAndroid向けアプリ紹介開発者に、配布手段がない問題を解決するつもりだった。Tsukuttaにアップロードしてリンクを発行できる。
実際の結果: ファイル配布のアプリは3件。
これも見立てが外れた:
1. 「自分が便利と思うもの」と「ユーザーが使うもの」は別物。 MCPサーバーは自身の生活動線の中では完璧に動く。でも私はユーザー全体のうちの一人でしかない。
2. 使用率は仮説検証のシグナル。 1%という数字を「もっと宣伝すれば伸びる」と読むか、「想定したペルソナが実在しなかった」と読むかで、次の判断が変わる。今回は後者だった。
3. 力を入れた機能が必ずしも刺さらない。 MCPサーバーは設計+実装+セキュリティ強化(レート制限/サニタイズ)に相当工数を入れた。それでも刺さらない時は刺さらない。
両機能とも消す気はない。3人でも価値を出せている人がいるなら維持する。
代わりにいま見ているのは、フォーム経由で投稿されたユーザーが、次に何を欲しがっているか。リクエスト機能、記事、ランキング、フォロー機能 ── ここに来た人が「もっと使いたい」と思える理由を、データに沿って一つずつ重ねていく。
外したのは辛いけど、上記の事を認識できたのは、よかったと思っている。