Launch HN:Unlayer(YC W22)——为你的应用添加电子邮件和文档构建器
Launch HN: Unlayer (YC W22) – Add email and document builders to your app
我们发现了什么
Unlayer 让你能以三种不同方式在应用内创建电子邮件、网页和文档:通过代码、可视化方式或AI。其中越来越多的内容也由AI智能体生成。
- 来源:Hacker News(发现于 2026-07-23)
- 证据等级:D · 发现产品或需求信号,暂未获得可核验的商业证据。
- 商业模式:Subscription SaaS
- 主题:独立产品
- 初筛评分:22.4/100 · 收录 1 次
证据,比故事更重要。
规则清洗与初筛,未经人工商业核验。原文语境、实际客户和付费情况仍需自行验证。
引用与数字披露
来源类型(原作者自述/第三方测算/媒体转引)需采集端标注,本版尚未落字段。
- 作者
- 未标注
- 抓取日期
- 来源类型
- 未标注
- 币种
- 未标注
- 口径
- 未标注
- 披露主体
- 未标注
- 披露日期
- 未标注
中文辅助译文(来源摘要)
你好,HN,我们是 Adeel 和 Umair,Unlayer(https://unlayer.com/ )的联合创始人。我们让你能够在应用中集成内容创作功能,而无需自己构建整个编辑器、渲染器、模板和导出流程。Unlayer 可以让你在应用内部以三种不同的方式创建电子邮件、网页和文档:代码方式、可视化方式或 AI 方式。演示视频请见:https://www.youtube.com/watch?v=0HsDtNkdMpM 。我们最初是从可嵌入的邮件编辑器开始的,因为很多产品最终都会需要它:CRM、营销工具、客户互动平台、市场交易平台、内部工具以及垂直 SaaS 应用最终都会遇到这个问题。起初,这听起来像是一个小功能:"只是"加一个拖拽编辑器而已。但在实践中,它会变成一个大麻烦。你最终要处理邮件渲染、Outlook 的怪异行为、响应式布局、模板、合并标签、图片上传、导出、权限、本地化、版本控制,以及一长串与你的核心产品无关的边缘情况。随着时间的推移,我们看到了邮件之外同样的问题。应用也需要登录页、发票、方案书、报表、合同和 PDF。其中一些内容最适合由终端用户可视化创建。其中一些更适合由开发者以代码方式生成。越来越多的内容也由 AI 智能体生成。许多团队最终需要这三种工作流。这就是我们一直致力于 Unlayer 的方向。今天我们要展示的包含三个部分: (1)Unlayer Elements。
这是我们的开源 React 组件库,用于以代码方式创建电子邮件、页面和文档(代码仓库:https://github.com/unlayer/elements ,更多信息请见 https://unlayer.com/elements )。开发者无需手工编写原始 HTML 模板,而是可以使用 React 组件来组合内容,复用页眉、页脚、CTA、发票行和品牌区块等部分,将模板保存在 Git 中,并将它们渲染为可用于生产环境的输出。我们看到的一个较新的用例是 AI 辅助的内容创作。如果 AI 智能体被要求创建电子邮件、发票、报表或登录页,输出通常是原始的 HTML 或 markdown,难以维护。使用 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 智能体应该能够生成结构化内容,而不是难以维护的大块文本。最终输出仍然应该可供宿主应用使用。我们的商业模式是向将 Unlayer 嵌入其产品的公司销售托管构建器、模板、导出和平台功能。Elements 是开源的。商业产品是围绕构建器、协作、存储、导出和生产用例的更广泛的托管平台。我们参加了 W22 批次,所以这是一次迟到的 Launch HN。当时 Unlayer 还只是一个可嵌入的邮件编辑器,我们认为还没有准备好向 HN 讲述更宏观的故事。从那时起,产品已扩展为产品中更通用的内容创作层,包括电子邮件、页面、文档、API、开源开发者项目和 AI 辅助工作流。现在似乎是一个更好的时机将它带到 HN 并寻求反馈。我们将非常感谢 HN 的意见。这是一个很多人都有强烈看法的领域,因为他们曾被编辑器、邮件 HTML、文档编辑或所谓"简单"的内容工作流所困扰。我们很乐意听听什么引起了你的共鸣,什么听起来不对劲,以及你认为我们应该在哪些方面进行更深入的思考!
译文由上游机器翻译生成,可能有误;判断请以英文原文为准。
英文原文(来源本站未改写)
Hi HN, We’re Adeel and Umair, co-founders of Unlayer ( https://unlayer.com/ ).We let you add content creation to your applications without having to build an entire editor, renderer, template, and export stack yourself.Unlayer lets you create emails, web pages, and documents inside your app, in three different ways: in code, visually, or with AI.Here’s a demo: https://www.youtube.com/watch?v=0HsDtNkdMpM .We started with an embeddable email editor because a lot of products eventually need one: CRMs, marketing tools, customer engagement platforms, marketplaces, internal tools, and vertical SaaS apps all run into this at some point.
At first, it sounds like a small feature: "just" add a drag and drop editor.In practice, it turns into a big pain.You end up dealing with email rendering, Outlook quirks, responsive layouts, templates, merge tags, image uploads, exports, permissions, localization, versioning, and a long tail of edge cases that have nothing to do with your core product Over time, we saw the same problem beyond email.Apps also need landing pages, invoices, proposals, reports, contracts, and PDFs.Some of this content is best created visually by end users.Some of it is better generated in code by developers.Increasingly, some of it is also generated by AI agents.Many teams eventually need all three workflows.
That is the direction we have been working toward with Unlayer.There are three parts we are showing today: (1) Unlayer Elements .This is our open-source React component library for creating emails, pages, and documents in code (repo: https://github.com/unlayer/elements , more at https://unlayer.com/elements ).Instead of hand-writing raw HTML templates, developers can compose content using React components, reuse sections like headers, footers, CTAs, invoice rows, and branded blocks, keep templates in Git, and render them into production output.One newer use case we are seeing is AI-assisted content creation.
If an AI agent is asked to create an email, invoice, report, or landing page, the output is usually raw HTML or markdown that becomes hard to maintain.With Elements, the agent can generate structured React components instead.A developer can review the result, refactor it, keep it in Git, and still pass the design into a visual builder later if someone needs to edit it. (2) Visual Builder .This is the drag and drop editor (repo: https://github.com/unlayer/react-email-editor , more at https://unlayer.com/email-builder ) that can be embedded inside an app so non-technical users can create or edit content.In the demo, we show the email builder and the AI assistant inside the builder.
The goal is not to replace the developer workflow, but to connect it with a visual workflow when marketers, admins, customers, or internal teams need to make changes themselves. (3) Document Builder .This is for structured documents such as proposals, reports, invoices, contracts, and PDFs.We have seen a lot of teams build separate systems for email templates, web pages, and document generation, even though the underlying primitives are similar: layout, content blocks, variables, assets, preview, export, and permissions.More: https://unlayer.com/document-builder The technical challenge is making these workflows share a common foundation.
Developers should be able to build templates in code when that makes sense.End users should be able to edit visually when that makes sense.AI agents should be able to generate structured content instead of unmaintainable blobs.The final output should still be usable by the host application.We make money by selling hosted builder, template, export, and platform features to companies embedding this into their products.Elements is open source.The commercial product is the broader hosted platform around builders, collaboration, storage, exports, and production use cases.We were part of W22, so this is a late Launch HN.
At the time, Unlayer was an embeddable email editor, and we did not think we had the right broader story for HN yet.Since then, the product has expanded into a more general content creation layer for products, including emails, pages, documents, APIs, open-source developer projects, and AI-assisted workflows.That felt like a better moment to bring it to HN and ask for feedback.We'd really appreciate thoughts from HN.This is one of those areas where a lot of people have strong opinions because they’ve been burned by editors, email HTML, document editing, or “simple” content workflows before.
We'd love to hear what resonates, what sounds wrong, and what you think we should be thinking harder about!
这条还缺什么证据?
下面每条都由本条已有字段推出(等级、理由、商业模式、来源次数、是否演示), 本站不生成推测性结论;通用验证方法放在方法论页。
- 可核验的收入或付费证据查官网定价页与付费口径;第三方数据源(如 GetLatka)只作旁证,需标注来源与时点。
- 只有单一来源找一手站点或其他渠道是否重复出现同一产品;社区热帖数量不等于商业进展。
通用验证清单(谁有这个问题/谁愿意付费/一个人能交付哪一小步)见我们的筛选方法。