HN 日本語サマリー

← 一覧へ戻る
Web開発

Launch HN: Unlayer (YC W22) – アプリにメールおよびドキュメントビルダーを追加

Launch HN: Unlayer (YC W22) – Add email and document builders to your app (unlayer.com)

48 pointsby adeelraza33 コメント

要約

Unlayerは、開発者が自社アプリケーションにコンテンツ作成機能(メール、ドキュメント、ウェブページビルダー)を容易に追加できるプラットフォームです。コード、ビジュアル、AIの3つの方法でコンテンツ作成をサポートし、当初はメールエディターから始まりましたが、現在はより広範なドキュメント作成機能も提供しています。オープンソースのReactコンポーネントライブラリと商用ホストプラットフォームを通じて、開発者とエンドユーザー双方のニーズに応えます。

全文翻訳

HNの皆さん、こんにちは。私たちはUnlayer(https://unlayer.com/)の共同創業者であるAdeelとUmairです。私たちは、エディター、レンダラー、テンプレート、エクスポートスタック全体を自社で構築することなく、アプリケーションにコンテンツ作成機能を追加できるようにします。Unlayerを使用すると、コード、ビジュアル、またはAIの3つの異なる方法で、アプリ内でメール、ウェブページ、ドキュメントを作成できます。 デモはこちらです: https://www.youtube.com/watch?v=0HsDtNkdMpM 私たちは、多くの製品が最終的に必要とする埋め込み可能なメールエディターから始めました。CRM、マーケティングツール、カスタマーエンゲージメントプラットフォーム、マーケットプレイス、内部ツール、バーティカルSaaSアプリは、すべてある時点でこれに直面します。最初は、それは小さな機能のように聞こえます。「ドラッグ&ドロップエディターを追加するだけ」です。しかし実際には、それは大きな苦痛になります。メールレンダリング、Outlookの癖、レスポンシブレイアウト、テンプレート、マージタグ、画像アップロード、エクスポート、権限、ローカライゼーション、バージョン管理、そしてあなたのコア製品とは関係のないエッジケースのロングテールに対処することになります。 時間が経つにつれて、メール以外の分野でも同じ問題があることに気づきました。アプリは、ランディングページ、請求書、提案書、レポート、契約書、PDFなども必要とします。これらのコンテンツの一部は、エンドユーザーがビジュアルで作成するのが最適です。一部は、開発者がコードで生成する方が適しています。そして、ますます多くのコンテンツがAIエージェントによって生成されるようになっています。多くのチームは、最終的にこれら3つのワークフローすべてを必要とします。これが、私たちがUnlayerで目指してきた方向性です。 本日ご紹介するのは、3つの部分です。 (1) Unlayer Elements。これは、コードでメール、ページ、ドキュメントを作成するためのオープンソースReactコンポーネントライブラリです(リポジトリ: https://github.com/unlayer/elements、詳細は https://unlayer.com/elements)。開発者は、生のHTMLテンプレートを手書きする代わりに、Reactコンポーネントを使用してコンテンツを構成し、ヘッダー、フッター、CTA、請求書行、ブランドブロックなどのセクションを再利用し、テンプレートをGitに保持し、本番出力にレンダリングできます。 最近見られる新しいユースケースの1つは、AI支援によるコンテンツ作成です。AIエージェントにメール、請求書、レポート、またはランディングページを作成するように依頼された場合、その出力は通常、メンテナンスが困難になる生のHTMLまたはマークダウンです。Elementsを使用すると、エージェントは代わりに構造化されたReactコンポーネントを生成できます。開発者は結果を確認し、リファクタリングし、Gitに保持し、後で誰かが編集する必要がある場合は、ビジュアルビルダーにデザインを渡すことができます。 (2) Visual Builder。これは、非技術ユーザーがコンテンツを作成または編集できるように、アプリ内に埋め込むことができるドラッグ&ドロップエディターです(リポジトリ: https://github.com/unlayer/react-email-editor、詳細は https://unlayer.com/email-builder)。デモでは、メールビルダーとビルダー内のAIアシスタントを示しています。目標は、開発者のワークフローを置き換えることではなく、マーケター、管理者、顧客、または内部チームが自分で変更を加える必要がある場合に、ビジュアルワークフローと接続することです。 (3) Document Builder。これは、提案書、レポート、請求書、契約書、PDFなどの構造化されたドキュメント用です。私たちは多くのチームが、メールテンプレート、ウェブページ、ドキュメント生成のために別々のシステムを構築しているのを見てきました。基盤となるプリミティブは、レイアウト、コンテンツブロック、変数、アセット、プレビュー、エクスポート、権限など、類似しているにもかかわらずです。詳細: https://unlayer.com/document-builder 技術的な課題は、これらのワークフローが共通の基盤を共有できるようにすることです。開発者は、コードでテンプレートを作成することが理にかなっている場合に、それを行うべきです。エンドユーザーは、ビジュアルで編集することが理にかなっている場合に、それを行うべきです。AIエージェントは、メンテナンス不可能なブロブではなく、構造化されたコンテンツを生成できるべきです。最終的な出力は、ホストアプリケーションによって引き続き使用可能である必要があります。 私たちは、これを製品に組み込んでいる企業に、ホストされたビルダー、テンプレート、エクスポート、およびプラットフォーム機能を販売することで収益を得ています。Elementsはオープンソースです。商用製品は、ビルダー、コラボレーション、ストレージ、エクスポート、および本番ユースケースを中心とした、より広範なホストプラットフォームです。 私たちはYC W22の参加者だったので、これは遅いLaunch HNです。当時、Unlayerは埋め込み可能なメールエディターであり、HN向けのより広範なストーリーはまだないと私たちは考えていました。それ以来、製品はメール、ページ、ドキュメント、API、オープンソース開発者プロジェクト、AI支援ワークフローを含む、製品向けのより一般的なコンテンツ作成レイヤーに拡大しました。これは、HNに持ち込み、フィードバックを求めるのに適した時期だと感じました。 HNからの意見をいただけると大変ありがたいです。これは、多くの人々がエディター、メールHTML、ドキュメント編集、または「単純な」コンテンツワークフローで苦い経験をしたことがあるため、強い意見を持っている分野の1つです。何が共感を呼び、何が間違っているように聞こえ、そして私たちがもっと真剣に考えるべきことは何か、ぜひお聞かせください!