Breaking WYSIWYG Limitations: How Novu and Maily Are Changing Email Editing

I recently sat down with Ark Chakma, the creator of Maily, and the Novu VP of engineering Sokratis (aka Sok) Vidros to discuss how we’re working together to deliver on a shared vision: finally produce an email block editor that doesn’t suck.

We’re not just using Maily like a library in Novu. We’re actively working with Arik to drive features, fix bugs, and ultimately help Maily to be the best email block editor there is.

Success requires that we work together for the betterment of both platforms, which will not happen by accident. If you have a product, and you’re looking to work closely with an open source project, read along to learn how we’re doing it.

But first, some more background…

Building the future of email editors – the open source way

If you’ve ever tried to use an email editor, chances are you’ve had that moment of frustration: it’s either too simplistic, doesn’t quite work as advertised, or locks you into some proprietary system. That’s where Maily and Novu come in, working together to change the game and solve the age-old problem of email design.

This post is all about how we’re doing just that: combining the strengths of open source collaboration, working through the challenges of making tools that are both powerful and simple, and giving you a sneak peek of the cool features we’re building along the way.

Why open source makes this possible

Open source isn’t just a buzzword for us; it’s at the core of why we’re able to do what we do. It’s the foundation that lets us innovate quickly and combine ideas from different teams with a shared vision for the future of email editors. And that’s how Arik from Maily and Sokratis from Novu came together.

Sokratis described how it all began: 

“Internally, we discussed using piped-up with React Email for rendering, and I opened the GitHub repo and found Arik had done exactly that. It just clicked—like we had to talk.”

That’s the beauty of open source—you can have developers in different parts of the world working on similar problems, and suddenly, two projects can come together to create something far more powerful.

Innovation in the open-source way

One of the great things about open-source collaboration is how ideas snowball. Arik had a clear vision for Maily: a block editor that works across platforms. But once Sokratis joined in, the project expanded in ways even Arik hadn’t imagined. For instance, introducing loops—allowing dynamic content to be rendered based on data—was a total game-changer.

As Arik said, 

“Sokratis brought up ideas I hadn’t thought of—like loops and other advanced features—and I just kept thinking, ‘Wow, this is great, let’s do it!’” 

This kind of back-and-forth is what open source is all about.

How we’re working together

Integrating an independent open-source project is much harder than just grabbing the libraries and making the changes needed to get it to work. We didn’t want Novu’s version of Maily. We want Maily’s version of Maily, and we want to help make it even more amazing.

We’re not just merging ideas. We’re working together closely, constantly bouncing ideas off each other, tweaking designs, and making sure they’re building something that’s both simple and powerful. It’s collaborative all the way through.

Right now, we’ve built about 70% of the core features and are refining the UX. As Arik puts it, 

“We’re constantly discussing how to improve the UX… what happens when you click this, or how should it behave when you do that?” 

This hands-on collaboration keeps things moving forward so quickly, and the results will be apparent.

In the beginning, we sought to understand Arik’s motivation and desires for his project. This is an important step when working with project creators. Understanding their goals and finding ways to empower them to succeed will be critical in any relationship like this.

Find a shared vision

When selecting open-source projects to work closely with and guide, a shared vision is key to keeping us all on the same page. Our shared vision is the desire to build something powerful enough for notification developers but also simple enough to use without always having to dive into code. A shared vision is a must before collaboration at this level can succeed, and the clearer it is, the better.

We also jointly recognize that the tools developers use are key to creating amazing product experiences.

Sokratis summed it nicely: 

“If you make your developers happy, the product will be good.” 

That ethos drives every decision we make—we focus on simplicity first and ensure the user experience doesn’t get bogged down in complexity.

And a shared understanding of the job to be done

Arik built Maily to solve a problem: he wanted to quickly create emails without lifting his hands from the keyboard… but also not by direct coding. A notion-like block editor was the answer. The mouse is always there when you really need it. Still, with a goal of making it a good experience for developers, it’s easier to make the right feature decisions rather than end up down a dead-end road of never-ending feature requests that further complicate something that was intended to be simple and easy to use from the get-go. And that’s where typical WYSIWYG editors fall.

Breaking the WYSIWYG myth

So many developer tools are created to make it easier to solve complex developer problems. A great example is Ansible, which Michael Dehaan created because he was tired of learning and re-learning how to use Puppet. But that pattern also has a trap.

Here’s the thing about most of the WYSIWYG (What You See Is What You Get) editors out there: they promisesimplicity but rarely deliver it. Sure, you can drag and drop some blocks, but when you try to do something more advanced, you quickly hit a wall or are severely limited. Suddenly, you’re writing custom HTML, or even worse, breaking the whole design.

Sokratis mentioned…

“It’s really hard from a UX perspective to nail that balance where you can do anything you want without completely injecting code.” 

That’s the gap we’re working to fill. We want to create a tool that’s not just for product teams but one that developers will love, too.

Why is solving this so hard?

We’ve all been there: you’re using a drag-and-drop editor, and it’s working fine until you need to make a tiny tweak, and suddenly, you’re wrestling with code. Tools like HubSpot’s editor are great for simple tasks, but the second you try to customize things—like adjusting paragraph spacing—you’re knee-deep in HTML.

And then there’s Webflow, which is incredibly powerful but feels like Adobe Photoshop for web design—great if you know what you’re doing, but overwhelming for most people. As Arik explained, 

“Drag and drop works until you start doing advanced stuff, and then it gets really messy.”

Many tools also have the challenge of lock-in. Many WYSIWYG editors fall into this category. The design may spit out raw HTML, but that hardly ever is constructed in a way that makes it easily editable by anything other than an IDE.

Our combined solution: flexibility without complexity. This new block editor lets users start with simple designs, and scale those up as needed—without ever feeling locked into the tool’s limitations. Together with Arik, we’re focusing on intuitive design decisions that don’t sacrifice power. It’s all about giving developers the flexibility they need while keeping things user-friendly for everyone.

Why simplicity beats complexity

Simplicity is very hard to achieve. It takes time, careful thought and consideration, and a deep understanding of the problem and desired solution. And also patience.

As Pascal once said, 

“I have made this letter longer than usual only because I have not had the time to make it shorter.”

The simple solution is often the elegant solution.

Complexity might seem impressive at first, but it rarely leads to long-term success. Both Arik and Sokratis are huge advocates of keeping things simple, and that’s a philosophy baked into every decision we collectively make. Simplicity isn’t just about ease of use—it’s about ensuring that the product is scalable, maintainable, and easy to iterate on.

As Arik said, 

“Keeping things simple is always the best way to build software. The more complex it is, the more it breaks.” 

And that’s the approach we’re taking with Maily and Novu.

Our advice: simplicity wins, and the first solution is rarely the best one. Keep at it.

Cool things we’re working on together

Joint innovation has already delivered a lot of interesting ideas for what we hope will become everyone’s favorite editor…

We’re really excited about some upcoming features like loops and dynamic content. With loops, users can create a template and have it dynamically render multiple items, making it perfect for things like notification digests or transaction emails. Imagine getting a digest from Notion or Figma that lists all your updates—that’s exactly the kind of dynamic content we’re building.

We’re also focusing on making it easier to customize layouts without needing to write custom code. You’ll be able to tweak things like columns, padding, and margins directly in the editor, without ever touching the underlying HTML. It’s all about giving users control, without the headaches.

And that’s just the start. Once we launch the first version of this in November 2024, we’re not stopping.

Wrapping it up

At the end of the day, this collaboration between Maily and Novu is about more than just building a great email editor—it’s about rethinking how we approach design and development in a way that’s both simple and flexible. Open source has made this possible, and the innovations coming out of this partnership are just the beginning.

Stay tuned as we roll out more features, refine the UX, and keep pushing the boundaries of what email and notification editors can do. We’re just getting started.

Full video of the discussion is coming soon!