4つのプロダクトを一人でリリースして
1年間で4つのプロダクトをリリースしました。
AIスマートコントラクト監査ツールからB2B SaaSまで、多岐にわたります。
これらを一人で構築したことで、単一のプロジェクトでは得られなかった教訓を得ることができました。
学んだことは以下の通りです。
- 「退屈な作業」に備えておく 私は技術的に難しい部分、つまりAI分析やバイトコードの再構築といったことにばかり時間を費やしていました。それらは困難ではありましたが、予測可能なものでした。
本当の脅威は、退屈な部分にありました。Chrome Web Storeの審査やデプロイの問題によって、プロジェクトが頓挫しかけたこともあります。真の仕事は、華やかさのない統合（インテグレーション）の中にあります。
- AIは最初の80%をこなしてくれる AIによって、開発の初期段階のコストが大幅に下がりました。スキャフォールディングやボイラープレートの作成をAIが担ってくれるため、一人での開発が可能になります。
しかし、AIは最後の20%を解決してはくれません。エッジケースへの対応、セキュリティレビュー、深いデバッグには、依然としてあなたの時間が必要です。AIはあなたをチームに変えてくれるわけではありません。単に、単純作業のコストを下げ、より頻繁にリリースできるようにしてくれるだけなのです。
リネームは進歩である 以前は、プロダクトの名前を変えることは努力の無駄だと考えていました。しかし、それは間違いでした。名前を変えるということは、プロダクトを十分に理解し、真のアイデンティティを与えられるようになったことを意味します。明快さは進歩なのです。
見た目より先にロジックを 美しいUIは罠です。進んでいないのに、進んでいるような錯覚に陥らせてしまいます。
私は今、一つのルールに従っています。デザインに触れる前に、ロジックとテストを完成させることです。コードが壊れたときにテストが失敗する状態になって初めて、その機能は動作していると言えます。見た目を整えるのは、その後のことです。
- Build in public（公開しながら作る） 何か素晴らしいものができた時まで待つ必要はありません。バグや失敗したアプローチについても書きましょう。
特定の課題をどう解決したかを書くことで、適切な人々を惹きつけることができます。そうした人々が、あなたのユーザーや協力者になっていくのです。
もしあなたが一人で開発しているなら：
• 退屈な統合作業のための計画を立てる。 • 大まかな作業にはAIを活用し、難しい20%は自分で行う。 • デザインよりもテストとロジックを優先する。 • 進捗に合わせてプロセスを書き記す。
リリース（Shipping）は目的地ではなく、動詞である。