A developer's journey from frustration to building a free tool that solves a problem nobody wants to talk about
Disclosure: I wrote this post and used ChatGPT to polish the writing. Per DEV guidelines, I'm disclosing that AI was used for editing and refinement while all the technical details and founder perspective are entirely from my own experience.
The Problem I Lived Every Day
I'm a developer. And before I built MailViewr, I was stuck in a pattern I've seen countless times across the industry.
Someone from marketing or management would ping me on Slack: "Hey, can you put together an HTML email for this campaign? You know HTML, right?"
And just like that—I'd become the email developer.
Not because I wanted to. Not because I'd chosen to specialize in email. Just because the assumption was simple: HTML is HTML. If you can build a website, you can build an email.
That assumption is dead wrong.
The Moment I Decided to Build Something
The turning point came after my email—one I'd spent hours perfecting—arrived in my users' inboxes looking nothing like I'd designed it.
It was perfect in Chrome. Broken in Outlook.
I'd styled it with flexbox, border-radius, modern CSS. All standard, all expected. Except Gmail strips <style> blocks. Outlook uses Microsoft Word to render HTML (not a browser). Apple Mail has its own rules. And mobile? That's a completely different world.
I spent hours debugging. Testing in Chrome. Testing in Firefox. Sending test emails to myself on Gmail. On Outlook. On my phone. Checking again. Making a change. Sending again.
And I still missed things.
The real wake-up call: Litmus starts at $99/month. Email on Acid isn't cheap either. These tools are built for teams with real email budgets. Not for developers like me who got handed a one-off task and told, "Just figure it out."
Why Nothing Existed for Developers Like Me
There's a massive gap in the email tools market. On one end: enterprise solutions like Litmus for dedicated teams with budgets. On the other: nothing.
The problem is knowledge, not budget. No bootcamp teaches MSO conditional comments. No web development course covers Gmail clipping limits or Outlook's Word rendering engine. You're expected to just... figure it out.
So I decided to build what I needed.
How MailViewr Started
The idea was simple: give developers a tool to test HTML emails properly before sending them.
Most email preview tools just render HTML in a browser—which tells you almost nothing about real client behavior. Instead, I built MailViewr around real email client rendering rules, continuously updated as clients evolve.
A Real Technical Problem I Hit
Let me give you a concrete example of the kind of thing that drove me to build this.
I had a campaign email with a two-column layout. Beautiful in Figma. Responsive flexbox in the code. It looked perfect in Chrome, Firefox, and my email client.
Then it went out. And in Outlook? Total disaster. The columns collapsed into a single line. The spacing was wrong. The background color on one section disappeared entirely.
The culprit: Outlook doesn't support flexbox or even some basic CSS properties.
Here's what I learned to do:
<!-- Instead of flexbox, use nested tables for layout -->
<table role="presentation" width="100%">
<tr>
<td width="50%" style="padding: 20px; background: #f5f5f5;">
Column 1
</td>
<td width="50%" style="padding: 20px; background: #ffffff;">
Column 2
</td>
</tr>
</table>
<!-- Use MSO (Microsoft Office) conditional comments for Outlook-specific fixes -->
<!--[if mso]>
<style>
.hide-mobile { display: block !important; }
</style>
<![endif]-->
<!-- Inline all critical CSS, don't rely on <style> blocks -->
<p style="font-family: Arial, sans-serif; color: #333; line-height: 1.6;">
This will work everywhere.
</p>
The lesson: Email requires defensive CSS. You can't use modern techniques because you're building for clients from 2003 (Outlook) and custom rendering engines (Gmail). You build in layers: tables for layout, inline styles as baseline, then progressive enhancement with CSS that won't break if stripped.
This is why testing across clients isn't optional—it's how you discover what actually works.
The Impact I've Seen
Since launching, I've watched developers catch Outlook rendering issues before sending to 500 subscribers. I've seen freelancers save countless hours of trial-and-error testing. I've seen non-technical team members build professional emails without touching code.
The comments I get are always the same: "I thought I was crazy. I thought I was bad at HTML because my email looked broken in Outlook." No—you're not bad at HTML. Email development is just a completely different discipline.
What's Next
We're continuously expanding client coverage and improving compatibility detection. The goal is to make email testing something developers don't have to be afraid of.
In Closing
If you've been handed an email task and felt lost—you're not bad at HTML. Email development is just fundamentally different from web development. It requires different knowledge, different techniques, and frankly, better tools.
If this resonates with you, or if you've got your own email disaster story, I'd genuinely love to hear it in the comments. Those conversations are what push me to keep building.
Feel free to check out mailviewr.com if you're curious. Use it, don't use it—the goal was to build something useful, and hearing that it actually helps developers is reward enough.
What's your worst email rendering nightmare? Drop it below—I want to know I'm not alone in this.
MailViewr is free, no account required, because the tool exists specifically to solve a problem that shouldn't require a subscription.
Top comments (7)
The MSO conditional comments section alone is worth the read. I’ve been doing email dev on and off for 3 years and I still google this stuff every single time. Nobody warns you that Outlook literally renders HTML through Word — like that’s insane when you think about it. Saving this post.
Haha right — the Word rendering thing sounds like a joke until it’s your layout collapsed in someone’s inbox at 9am.
Glad the MSO section landed. That’s exactly the stuff nobody tells you upfront.“
Respect for shipping something free with no signup wall. That’s a deliberate choice and it costs you. We went the opposite route early on — gated everything — and our word-of-mouth was basically zero for the first 6 months. The tool looks solid. My only concern would be sustainability, how are you thinking about monetization long term? Free is great for growth but at some point the hosting bill shows up.
I appreciate the transparency about using ChatGPT for editing. Genuine question though — when you say “real email client rendering rules, continuously updated” — how are you maintaining that? Are you pulling from a database of known quirks, or is there some automated testing pipeline? That’s the part I’d want to understand before recommending this to my team. Not skeptical, just want to know what I’m vouching for.
One more question regarding security -
What is your data retention policy for uploaded templates, and specifically, do your server-side logs capture raw HTML payloads or metadata that could expose proprietary logic or PII?
Great questions — deserves a straight answer.
On the rendering rules: we maintain a proprietary compatibility database built from known email client behavior, validated and updated manually as clients evolve. It’s not an automated pipeline — it’s a curated dataset we actively maintain. Not magic, but it’s what makes the preview meaningfully more accurate than raw browser rendering.
On security: your HTML never touches our database. The preview runs entirely client-side in your browser — we don’t store, log, or process the HTML payload on our servers. No raw HTML in our logs, no retention of template content. This applies to test email sends too — we process the send action but never log or store the email content at any point.
Honest summary: solid for catching real rendering issues before send, not a replacement for Litmus if you need 100+ real device screenshots. But your proprietary template code stays on your machine.
This hits close to home from the other side of the table. I’ll be honest — I’ve been the person who pinged a dev asking for “a quick HTML email” without fully appreciating what that meant. We had a campaign go out with a broken layout in Outlook and I blamed the dev. Reading this made me realize I owe someone an apology lol. Bookmarking mailviewr.com for our next cycle, we’ve been eating the Litmus cost but $99/mo for something we use maybe twice a month is hard to justify.
That apology comment genuinely made my day — the fact that you even thought about it says a lot.
And yeah, $99/month for twice-a-month use is a rough math problem. We’re also adding a bunch of new features soon — all free. Hope MailViewr covers everything you need when the next cycle comes around.“