MailBurn Case Study: Building a Full Email Infrastructure SaaS From Scratch
Quick answer: MailBurn is a hosted SMTP and email warmup SaaS engineered by NeuroStackOS from raw infrastructure up, running Haraka for mail transfer, Dovecot for IMAP, PostgreSQL and Redis for data and queueing, and a custom BullMQ-driven warmup scheduler across a network of dozens of mailboxes. It is the most technically dense build in the NeuroStackOS portfolio, and it involved diagnosing and solving a hard cloud infrastructure blocker that most teams would not catch until production traffic exposed it.
What Email Deliverability SaaS Actually Requires
Most SaaS products can be built almost entirely at the application layer: a frontend, an API, a database, done. Email infrastructure is different, because the product itself is the deliverability of outbound mail, which means the build has to go all the way down into mail transfer agents, IMAP servers, and the reputation mechanics of how mailbox providers like Gmail and Outlook decide whether a message lands in the inbox or the spam folder. There is no framework that abstracts this away. It has to be built at the systems level.
MailBurn exists to solve a real, well-known problem in cold outreach and sales: a brand-new mailbox with no sending history gets flagged by spam filters almost immediately, regardless of how good the message content is. Warming up a mailbox, gradually building sending reputation through a scheduled pattern of realistic email activity, is the standard fix, and it is exactly what MailBurn automates.
Achieve Similar Results
Don't leave your engineering outcomes to chance. Book a technical strategy call with our lead architects today.
Book a Technical Strategy Call →What We Built
| Layer | Technology | Role |
|---|---|---|
| Mail transfer agent | Haraka | Handles outbound SMTP mail transfer at the protocol level |
| Mail storage and retrieval | Dovecot | IMAP server managing mailbox storage and access |
| Primary database | PostgreSQL 14 | Stores account, warmup schedule, and reputation tracking data |
| Queue and cache layer | Redis | Powers the job queue and caching layer behind the warmup scheduler |
| Reverse proxy and process management | Nginx and PM2 | Routes traffic to backend services and keeps Node processes alive and restarting cleanly |
| Warmup scheduling engine | Custom BullMQ scheduler | Automates realistic, gradually scaling send-and-reply activity across the mailbox network |
| Frontend | Next.js | Client-facing dashboard for account and warmup management, built through Google Antigravity |
| Mobile companion | Flutter | Cross-platform mobile app for monitoring account and warmup status |
| Billing | LemonSqueezy | Handles subscription billing across the tiered pricing structure |
The infrastructure runs on a hardened Oracle Cloud Ubuntu 22.04 instance. Specific server addressing and access details are intentionally left out of this case study. Publishing infrastructure identifiers on a public marketing page is a basic operational security mistake, since it hands anyone reading the page a direct target for scanning and probing. A technical case study should prove engineering depth, not leak an attack surface.
The Hard Blocker Nobody Warns You About
Roughly a third of the way into building MailBurn's sending infrastructure, outbound mail from the Oracle Cloud instance stopped working entirely, with no useful error pointing at why. The cause turned out to be a well-hidden but well-documented policy: Oracle Cloud has blocked outbound traffic on port 25, the standard SMTP port, on free-tier accounts since June 2021, as a blanket anti-abuse measure. This is not something that shows up in a getting-started guide. It shows up when a working mail server that ran fine in local testing suddenly cannot send a single message in production.
This is exactly the kind of blocker that separates a team that understands infrastructure from a team that only understands frameworks. Diagnosing it required ruling out application-level bugs, firewall misconfiguration, and DNS issues before isolating the actual cause at the cloud provider's network policy layer. Once confirmed, the fix was not to fight Oracle's policy, but to route around it: Hetzner was identified and adopted as the clean alternative for outbound SMTP, since it does not impose the same blanket port 25 restriction on new accounts.
The Warmup Network
MailBurn's warmup scheduler operates across a real network of mailboxes rather than a simulated one, combining ten Gmail accounts with twenty-five hosted mailboxes for a coordinated warmup pool of thirty-five addresses. The scheduler uses this network to send and reply to realistic email traffic on a gradually increasing schedule, which is the mechanism that actually builds sender reputation over time. A warmup system tested only in isolation, without a real network of mailboxes generating real engagement signals, is not meaningfully different from no warmup system at all, which is why this network was built as core infrastructure rather than an afterthought.
Where MailBurn Stands Today
Being accurate here matters more than sounding impressive. MailBurn's core infrastructure, mail transfer, IMAP, the warmup scheduler, the billing integration, and both the web and mobile clients, is built and functional. AWS SES production access, needed for a portion of the platform's sending capacity at scale, was pending approval as of this writing. The honest way to describe MailBurn right now is as a fully engineered, infrastructure-complete SaaS platform in its final pre-launch stage, not yet a platform with a proven base of paying customers.
Verified and built:
- Full mail infrastructure stack, live and functional on hardened cloud infrastructure
- Warmup network of 35 mailboxes (10 Gmail, 25 hosted) actively used by the scheduler
- Three-tier pricing model designed: Connect at $19 per month, Hosted at $39 per month, Agency at $79 per month
- LemonSqueezy billing fully integrated
- Next.js web frontend and Flutter mobile app both built
In progress:
- AWS SES production access, pending approval at time of writing
- $50,000 monthly recurring revenue by year two, used as the target that shaped the pricing and tier structure, not a current result
How MailBurn Compares to Established Players
MailBurn was designed with a clear view of the existing market, including Instantly.ai, Lemwarm, Warmup Inbox, and Mailreach. The differentiator is not a claim of doing something no one else has thought of, warmup-as-a-service is a proven category, it is that MailBurn was built from the infrastructure layer up by the same team selling it, rather than assembled from third-party warmup APIs stitched onto a dashboard. That matters for a prospective client or partner evaluating technical depth: the team behind MailBurn has direct, hands-on experience with the actual mail transfer and deliverability mechanics the entire category depends on, not just the product layer sitting on top of it.
Why This Case Study Matters
If a client needs backend-heavy infrastructure, not just a good-looking frontend, MailBurn is the proof. Mail transfer agents, IMAP servers, queue-driven scheduling systems, and cloud networking edge cases are a different skill set from building a CRUD app, and this build demonstrates all of them, including the ability to diagnose and solve an infrastructure-level blocker that had nothing to do with application code.
Frequently Asked Questions
What is email warmup and why does it matter for deliverability?
Email warmup is the process of gradually building sending reputation for a new or dormant mailbox through a realistic, scheduled pattern of send and reply activity. Without it, a mailbox with no sending history is likely to be flagged by spam filters regardless of message quality.
Why did Oracle Cloud block outbound mail, and how was it solved?
Oracle Cloud blocks outbound traffic on port 25, the standard SMTP port, on free-tier accounts as an anti-abuse policy in effect since June 2021. The fix was identifying and migrating outbound SMTP handling to Hetzner, which does not impose the same restriction.
What's the difference between MailBurn and tools like Instantly.ai or Lemwarm?
MailBurn was engineered from the mail transfer and IMAP infrastructure layer up by the team operating it, rather than built as a dashboard on top of third-party warmup APIs, giving the team direct operational understanding of the deliverability mechanics the category depends on.
What tech stack powers MailBurn's SMTP infrastructure?
Haraka handles mail transfer, Dovecot handles IMAP, PostgreSQL and Redis handle data and queueing, and a custom BullMQ scheduler drives the warmup automation, all running behind Nginx and managed by PM2 on hardened cloud infrastructure.
Is MailBurn live and accepting customers right now?
The core infrastructure is fully built and functional. AWS SES production access, needed for a portion of sending capacity, was pending approval as of this writing, so MailBurn should be understood as infrastructure-complete and in its final pre-launch stage rather than an established platform with a proven customer base.
Related Case Studies
- Billr: another infrastructure-heavy SaaS build, this one on Cloudflare Workers rather than a dedicated cloud instance
- SelfOS: a comparably complex, multi-layer architecture case study for systems-thinking comparison
- Publixion: automated distribution infrastructure applied to a digital publishing business rather than email
Work With NeuroStackOS
If your business needs infrastructure-level engineering, not just an application built on someone else's managed services, this is the depth of build NeuroStackOS takes on. Get in touch to talk through what a backend-heavy build looks like for your product.