SaaSの新規たちあげは難しい

現職で、受託ではなくSaaSとしてサービスを展開しようという話が（だいぶ前から）あります。

「そろそろ開発着手したいね～」なんて会話をしているのですが、その際に考えるべきSaaSのアーキテクチャが難しい。

・マイクロサービスにするか？
・モノリスにするか？
・どのくらいのユーザー数を見込む？
・サービスが起動に乗るまで、可用性とコストどちらを優先して設計するか？

本気でサービスを成功させたいのであれば、可用性は重要な問題ですが、現職の場合、まずはコストが最優先でアーキテクチャが検討される傾向にあります。これは経営的な短期目線での判断としてはある意味正解かもしれない。
だけど、もし新規で開発したSaaSが軌道に乗った場合、目先のコストだけ考えてアーキテクチャを設計した場合、どうスケールアウトしていけば良いだろう？
（たとえば、Aurora RDSのDBクラスター内に顧客毎のデータベースを作成すればRDSの費用は節約できるけど、思い切りアンチパターン）

SRE観点だと、エラーバジェットやSLOが文化として根付いてないと、SaaSを安定稼働させるのは難しいのでは？という懸念もあり。またAWSアカウントの運用もマルチアカウントに移行する必要がある。
TeraformやCloudFormationなどのIaCの運用を徹底する事も必須課題となるけど現状の体制でそれが実現できるだろうか。

また、開発エンジニアのモチベーションも人によってバラバラなのも問題。モチベーションの管理はどうすればいいだろうか。仕組み化を徹底することにより、モチベーションに左右されない品質をいじできるだろうか。

現在の開発チームは受託開発に慣れている為、本番稼働しているプロダクトに機能を追加するという経験がまだない。SaaSを運用するのであればソースコード起因の事故対応も出てくると想定される。その際のオンコール体制はどうれば良いだろうか。なにで通知すればいいだろうか。

技術選定は？
エンジニアの好奇心のみで技術を選択することはアンチパターンかもしれないけど、エンジニアにとって刺激のある技術選定を行うことは離職率の低下に貢献するかも知れない。PHPに慣れているエンジニアが多いからまたPHPを採用するというのも合理的かもしれないけど、エンジニアの今後のキャリアを考えたらあえてGoやTypeScriptなど他の言語で開発してみるのもありかも知れない。
プロダクトが成功することも重要だけど、プロダクトの成長に伴ってエンジニアが成長実感していかないと、離職率があがりプロダクトの成長の妨げになるだろう。

SaaSをゼロから作るのであれば、考える事は山積。
そしてその意思決定に一つ一つ根拠が必要。

まだまだ考えが浅い。