制作会社向けのFóir

クライアントのサイトは1つのプロジェクトではなく、20番目です。Fóirは、20番目が1番目より安く済むように作られています。

制作会社の仕事の多くは似通っています。同じページモデル、同じブロックセット、同じ設定を、共有版を置く場所がなかったためにクライアントごとに作り直しています。

Fóirでは、スキーマを共有するクライアントは1つのプロジェクト内の組織になります。モデルはプロジェクトに一度定義され、すべての組織がその定義を継承し、コンテンツはそれぞれ分けて保たれます。クライアントが追加で必要とする場合は、組織が自分のモデルを追加でき、残りをフォークする必要はありません。

ビルドパイプラインは、すべてのサイトに届く必要があります。クライアントや1つのブランドの外注先は、ちょうど1つだけに届くべきです。

プロジェクトキーは、プロジェクト内のどの組織でも、1リクエストにつき1つずつ操作できます。組織に限定されたキーは、そのクライアントにだけ届きます。どのキーも、許可したモデルとオペレーションにだけ届きます。

クライアントのサインインがベンダーのドメイン上にあることは、提案の場で説明したくない話題です。

各プロジェクトは自分のサインインドメインと自分のブランディングを持つため、アカウント画面は私たちのブランドではなく、クライアントのブランドのものになります。

制作会社の仕事で厄介なのは、クライアントが離れたり、社内に引き取ったりするときのことです。

そのプロジェクトは、クライアントが所有するPostgresデータベースにエクスポートされ、アクセスルールも一緒に変換されます。きれいに引き渡せるので、最初の段階で提案しやすくなります。

作り直さずに済むもの

クライアント向けの構築で毎回同じになる部分が、すでに用意されています。

登録、パスワード、ワンタイムコード、ソーシャル、OIDC。クライアント自身のドメインで提供されます。

変換とレスポンシブなレンディションを備えたアセットライブラリと、ファイルに対するアクセスルール。

クライアントごとに使うシステムへの外部向けオペレーション。認証情報はリポジトリではなくボールトに保管されます。

将来の日時に公開し、まとめてロールアウトするので、キャンペーンが一斉に公開されます。

移行中も古いURLを維持し、コンテンツを持つ人が管理します。

対象のレコードに紐づくコメント。レビューがスクリーンショットだらけのスプレッドシートになりません。

フォールバックチェーン付きのフィールドごとの翻訳。第2の市場が後から加わるクライアント向けです。

オーディエンスごとに異なるコンテンツを、クライアント自身のモデルから定義し、リクエストごとに解決します。

プロジェクトを作成し、毎回の構築で使うモデルを定義して、最初のクライアントを組織として追加します。