こんにちはスープです。
スタートアップのお手伝いをしています。

プロトタイピング

価値検証のために、実装とリリース、ユーザーフィードバック収集のサイクルを繰り返し行います。
そのサイクルのスピードと精度が重要です。

メンテンナンス性を度外視できる場合

コードは書かれるよりも、人に読まれる時間のほうが長いので、一般的にきちんとした設計のコードを書くメリットは大きいです。

ただし、書き捨てのコードに限っては、動作すれば何でも良いため、基本的にどんな書き方でも支障がないです。
これはプロトタイピング用のコードに関しても同じことが言えますね。

リスク

中長期的な成長の阻害

問題になるのは、プロトタイピング目的で書かれたコードをメンテナンスしなければいけないときです。
プロトタイピングフェーズ後、目下のビジネス価値の実現のみにエンジニアリングリソースが割かれることは非常に多く、スケールしない設計のまま突き進んでしまうケースが多いのです。設計のひずみが日増しに大きくなり、3年もすると（早ければ半年程度で）身動きが取れない状態になります。

バッドコードにより、機能開発に必要なリソースは指数関数的に増えていきます。
また、フラストレーションを溜めた離職者が続出したり、プロダクトの成長が止まったりすることは日常茶飯事で、会社ごと吹き飛んだりするケースもあるらしいです。

訴訟、ブランド毀損

低品質なソフトウェアによってユーザーが損害を被った場合、訴訟に発展したり、それによってブランドイメージを毀損したりするリスクが存在します。
Uberの自動運転で死者を出す事故が起きているのは記憶に新しいですね。

リスクにどう対処するか

負債の管理

負債の性質と量を把握し、負債返済のロードマップを作成する必要があります。

また、負債を増やすステークホルダーの要求があった場合、開発者はそのリスクを指摘します。
ステークホルダーのほとんどの人たちは、負債によって発生するリスクを知らないので、当該システムのことを知っているプログラマーにその責任がありますね。

一般的に、CTOやソフトウェアアーキテクト、テックリード等がソフトウェアのアーキテクチャへの影響をコントロールする役割を率先して担えるでしょう。

変更によって増す複雑性とそれによって追加される機能性を天秤にかけ、機能性の方が低いと判断される場合は、その変更は受け入れられません。

ステークホルダーとのコミュニケーション

プロトタイピングフェーズである旨をステークホルダー皆が認識する必要があります。
価値検証が終わったら、後にソフトウェアのリライト（フルリライトもしくはパーシャルなリライト）をすることをチーム全体、またステークホルダー達と握っておく必要があります。

ステークホルダーには、下記の人たちが含まれるはずです。

CEO
投資家
PO
開発チーム
Salesチーム
その他影響を受けるチーム
エンドユーザー

まとめ

ソフトウェアがどのフェーズに位置しているかを理解するのは重要ですね。
リスクを管理し、適切にステークホルダーとコミュニケーションを取っていくことによって、ソフトウェアが成功する確率を高めることができると思います。