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!
The hard part is usually what comes after: editable state, templates, email-safe HTML, PDF/export pipelines, assets, permissions, custom blocks, previews, and all the rendering edge cases that show up once real users depend on it.
AI also makes structure more important, not less. That’s why we launched Unlayer Elements: instead of having an LLM generate a static blob of HTML, it can target structured components that map back into an editable email, web page or document.
So I'd use AI to prototype it. I'd use Unlayer when that content layer becomes production infrastructure you don't want to maintain yourself.
For instance, the usage of "Totally fair" and "The hard part", the usage of colons, which humans would use far less frequently, using the rule of threes (editable email, web page or document), etc.
Anyway, it's just lazy. This is someone trying to sell their product. They should be able to speak about it without using the exact response from an AI
"""
Totally fair. You can build the first 10-minute demo with an LLM now.
The hard part is usually what comes after. You need editable state, templates, and email-safe HTML. Then come export pipelines, custom blocks, permissions, and all the rendering edge cases that show up with real usage.
AI makes structure more important, not less. That’s why we launched Unlayer Elements. Instead of having an LLM generate a static blob of HTML, it can target structured components that map back into an editable email, web page, or document.
So I'd use AI to prototype it. I'd use Unlayer when that content layer becomes production infrastructure you don't want to maintain yourself.
"""
I made a deslopper[1] tool based on a new skill[2] I saw on twitter earlier. It's still a little smelly imo, but better.
---
This is what I got first time with a humanizer I built, still sounds terrible:
"Yeah, an LLM gets you the 10-minute demo now.
The expensive part is everything after, once real users depend on it. You end up maintaining editable state, templates, email-safe HTML, export pipelines, asset handling, permissions, custom blocks, and live previews. That takes months.
Structure makes AI output usable here, and it gets more important as the workflow gets automated. That's the idea behind Unlayer Elements. The LLM generates real editable components that map back into the actual email or page, and you keep editing what it makes like anything else in the tool.
I'd prototype with the LLM. I'd bring in Unlayer once that content layer becomes real infrastructure you don't want to own yourself."
""" Making a demo that does some things is easy. Making a demo that does all the things is hard.
We took a lot of time to make this product polished. We nailed down a lot of UX gotchas and a lot of bugs that come from poorly written back-end code.
If you don't need the polish, then a demo is more than sufficient. We built this for those who just want to ship, not fight with their agent about tech stack stuff. """
I work outside of SV in the southeast and most businesses know AI is being used for products they use but they want experts in that field behind that.
Congrats on the launch - this looks like a genuinely useful tool. I look forward to checking it out.
A practical launch follow-up would be to look for live conversations from teams building AI-assisted invoice, proposal, report, or email workflows and getting stuck on that handoff from generation to editable production content. With the Unlayer positioning and ideal user as input, racoonn.me can surface those timely Reddit/X threads and produce reply drafts that address the stated implementation problem before mentioning the relevant builder or Elements workflow.
That is not a substitute for docs or examples around the component model. It is the discovery-and-first-response layer for finding people who are already trying to solve the exact problem you describe.
If that's the first impression you're giving, you're underselling what looks like a legitimately useful product :(
But your landing page + video was just slop city. Removes 100% of credibility for me.
I know the advice is launch early and often, but honestly I would just point people to the github until you have something better.
Sorry, but that's a no-go at this point.
Charge for the local version, of course.