4つのプロダクトを一人でリリースして
私は1年間で4つのプロダクトをリリースしました。
それらは spectr-ai、Scry、Argus、Lomi で、セキュリティ、Web3、ブラウザ拡張機能、B2B SaaS をカバーしています。
これらを一人で構築したことで、単一のプロジェクトでは得られない教訓を得ることができました。
学んだことは以下の通りです。
- 退屈な部分に工数を見込んでおく。
私は難しい技術的な問題にエネルギーを注いできました。AI分析やバイトコードの再構築に集中しました。これらは困難ですが、予測可能な部分でした。
本当の脅威は、華やかさのないタスクでした。Chrome ウェブストアの審査、プロキシの解決、デプロイの設定などが、プロジェクトを危うくさせました。
本当の仕事は、多くの場合、境界部分の統合（インテグレーション）にあります。私は毎回、これに対する見積もりが不足していました。
- AIは「始まり」を安くするが、「終わり」を安くするわけではない。
AIを使えば一人で会社を作れると言う人がいます。しかし、真実はもっと具体的です。
AIは機能の最初の80%を処理します。ボイラープレートを作成し、テストのドラフトを作成します。これにより、ソロでの開発が可能になります。
AIは最後の20%を処理できません。これには、エッジケース、セキュリティレビュー、不安定な接続のデバッグなどが含まれます。その部分は依然として時間がかかり、全神経を集中させる必要があります。
- リネーム（名前の変更）は進歩である。
プロジェクトの成長に合わせて、いくつかのプロジェクトの名前を変更しました。以前は、名前を変えることは努力の無駄だと考えていました。
それは間違いでした。名前を変更するということは、ようやくそのプロダクトを理解したということです。コードは同じですが、理解の明快さが向上したのです。
- 磨き上げる前に、ロジックを固める。
見栄えの良いUIは罠です。機能が変われば、デザインをやり直さなければなりません。これは時間の無駄です。
私のルールはシンプルです。スタイリングを行う前に、ロジックとテストを完了させることです。テストによって証明されて初めて、機能は動作したと言えます。動作するまでは、見た目を整えないでください。
- 失敗についても書く。
「Building in public（公開開発）」とは、悪い部分も共有することです。
私はハック、失敗したアプローチ、バグについて書きました。これは、黙々と作業するよりも多くのことを教えてくれました。また、あなたのプロセスに関心を持つオーディエンスを構築することにも繋がりました。
もし一人で構築するなら、以下のルールに従ってください：
• コア機能よりも、インテグレーションに多くの時間を割く。 • 単純作業にはAIを活用し、難しい20%は自力で行う。 • UIよりもテストを優先する。 • 進行過程で、自分の間違いも共有する。
リリース（Shipping）は動詞です。それは完了した状態を指すのではありません。4回リリースしたことは、一つのプロダクトを完璧にするよりも多くのことを教えてくれました。
Optional learning community: https://t.me/GyaanSetuAi