ここに来た理由は、おそらく次のいずれかです:
- 共有ログインドメインは本気の製品には不自然だと感じる
- セキュリティメールは自社製品のものだと明確であるべきだ
- アイデンティティとメールの複雑さが以前に問題を起こした
- 早いセットアップよりも構成要素を減らすことが重要だ
このページは時間を節約するためにあります。
AccountMakerは意図的なトレードオフを採用しています。このページでは、そのトレードオフが合う相手と合わない相手を説明します。
即時にホストされたログインページやマーケティングメールを求めているなら、おそらく適切なツールではありません。
次の条件なら適合します:
製品に外部ユーザーがいる
顧客、パートナー、クライアントがログインし、セキュリティ関連メールを受け取ります。
ログインとメールにすぐ信頼してほしい
ログインページとトランザクションメールを、プロバイダではなく自社ドメインから届けたい。
信頼と安全を製品機能として扱う
フィッシングリスクや混乱の低減を、基盤選定の評価軸にしている。
製品が長く続く前提で考える
一時的な足場ではなく、安定したアイデンティティの基盤を求める。
次の条件なら適合しない可能性があります:
すぐにホストされたUIが必要
AccountMakerは自社ドメインとアイデンティティ面の制御を前提とします。
マーケティングやアウトリーチのメールを送りたい
メールは認証と運用用途に限定されます。
短期間のプロトタイプを作っている
ドメインファーストのアイデンティティは、実験には重すぎることがあります。
匿名または使い捨てのアカウントが必要
AccountMakerは明確な所有とアイデンティティのシグナルを重視します。
適合性が重要な理由
AccountMakerは意図的に狭い範囲に絞っています。スコープを限定し、ドメインアイデンティティを強制することでリスクと曖昧さを減らしますが、その制約が目標に合っている場合にのみ機能します。
- ドメイン検証は初期の摩擦を生みます
- メール機能の制限により一部のユースケースは対象外になります
- アイデンティティの挙動は明示的で、魔法のようには動きません
よくある質問
小さく始めて後から変更できますか？
はい。多くのチームはAlphaで始め、予測可能性が必要になったらStableに移行します。
AccountMakerはアプリのUIを置き換えますか？
いいえ。AccountMakerはアイデンティティ基盤を扱い、製品UIは扱いません。