If you read the first three parts of our series, you know the broad strokes: We took a lean “Notion + GitHub + Amazon SES” setup, faced a massive Q4 Black Friday surge, hired a smart $500-a-month student developer, and coded our first Markdown-to-HTML converter script to survive. On paper, it sounds like a slick, heroic startup success story. In reality? Version 1.0 of our CLI tool was a total technical trainwreck. Below are links to articles from that series to give you a backstory:
The $0 Email Engine: How I Used Notion, GitHub, Amazon SES to Outsmart Email Service Providers
Monolithic Campaigns: How Micro-Tasking Cures Email Burnout
From Raw HTML Dumps to a CLI: How We Built LLazyEmail
It wasn’t a disaster because my student developer failed. It was a disaster because of three hard technical and psychological pillars that hit us right in the face.
If you’re a developer who has ever tried to build a “simple internal script” that slowly turned into an over-engineered nightmare, this post-mortem is for you.
Pillar 1: Markdown is a Terrible Editor for Edge-Case Content
Everyone in tech loves Markdown. It’s clean, lightweight, and stays out of your way. So the initial logic sounded bulletproof: Just write standard Markdown, use regex or a basic parser to convert it into HTML, and paste it into our pre-designed email template.
“Just write regex,” they said. “It will be easy,” they said.
Here is the problem: Email marketing isn’t just text and headings. Our newsletters needed custom structural blocks:
- Advertisement blocks with tracking parameters and specific padding.
- Meme and image blocks with centered captions and responsive wrappers.
- Call-to-Action (CTA) boxes with custom inline CSS buttons.
Standard Markdown syntax doesn’t support custom <div> containers or complex structural blocks out of the box. The moment we tried to invent our own custom tags or hack regex to handle edge cases, the parser fell apart.
If a draft contained an unexpected list item inside an ad block or an unclosed quote tag, the entire script would throw a fit or spit out broken HTML.
Me realized quickly that trying to force complex, high-converting email layouts into basic Markdown parser rules is like trying to build a sports car out of Lego bricks.
Pillar 2: The Procrastination Refactoring Loop (Me)
The second pillar holding us back wasn’t the code. It was me.
I am a professional procrastinator. I get easily distracted, and my brain is wired to avoid finishing painful tasks if I can find a clever developer excuse instead.
Every time our CLI script hit a bug or generated broken layout code, I had two choices:
- Apply a quick, ugly 5-minute band-aid fix so we could finish the newsletter and hit send.
- Spend four hours completely refactoring the codebase, reorganizing the folder structure, abstracting modules, and attempting to write unit tests.
Guess which one my procrastinating brain picked every single time?
So, I end up on this image
Instead of focusing on getting the fucking job done, I dragged myself and my student developer into a silo of chasing “clean code.” I would get obsessed with architectural perfection, try to cover everything with tests, get bored three days later, and wander off to something else.
I was using “best practices” as a psychological shield to avoid facing the immediate operational chaos of Q4.
Pillar 3: The Node.js Template Engine Rabbit Hole
Our initial technical setup was built on Node.js. The plan was simple: take the parsed Markdown text and inject it into a base HTML email layout using a basic template engine (like Handlebars or EJS).
It sounded fine on day one. By day thirty, it proved that handling email templates is an entire software engineering domain on its own. Inlined CSS rules in email behave like it’s 1999. Outlook ignores margin rules, Gmail clips code over 102KB, and Yahoo handles media queries differently than Apple Mail.
A basic Node.js string-replacement engine couldn’t handle:
- Conditional CSS rendering for Outlook (<!–[if mso]>).
- Automated CSS inlining at compile time.
- Dynamic asset pathing and web-safe font fallbacks.
The moment we realized our simple template script needed to handle all these edge cases, we hit a wall. To make this CLI actually work reliably, we weren’t just writing a converter—we were accidentally building a standalone email compilation engine from scratch.
Why That $500 “Disaster” Was Still a Huge Victory
Looking back, Version 1.0 failed at its immediate job:
- The code was a mess of half-baked refactors.
- The Markdown parser broke on complex blocks.
We spent money on student dev hours plus dozens of my own unpaid hours wrestling with Node.js scripts. But it was not a waste of time or money. But im over it. Right?
That broken script was the ultimate stress test. It proved that if you want to bridge low-cost infrastructure (Amazon SES) with simple “tools” (Notion/Markdown), you cannot rely on hacky local CLI scripts or basic regex parsers from Stackoverflow
It forced us to stop playing around with band-aids and gave us the exact blueprint for what a real, production-grade platform needed to do. It highlighted every bug, every edge case, and every psychological pitfall we needed to solve.
And that messy, bug-ridden, over-engineered CLI script is the exact reason LLazyEmail exists today.
