How I built a 🛠️ SaaS in my spare time

Sometimes, you see something and think “I can do that better.” And sometimes, you actually act on it.

That’s how MailShield started.

The itch

E-mail security is a mess of protocols bolted onto technology from 1971. DMARC was supposed to help. It lets domain owners define policies for unauthenticated e-mail and sends aggregate reports back so you can see what’s happening. Great in theory. In practice, those reports are XML files that look like this:

<record><row><source_ip>198.51.100.42</source_ip><count>23</count>
<policy_evaluated><dkim>fail</dkim><spf>pass</spf></policy_evaluated>
</row></record>

Nobody reads these. Most domain owners set up DMARC, configure a rua address, and never look at the reports again. That’s a problem, because those reports tell you exactly who is sending e-mail on behalf of your domain, authorized or not.

I wanted to fix that part. Not DMARC itself, but the “nobody reads the reports” part.

From idea to first version

I’d already built eSIM op reis as a side project, so I knew I could ship a product. But MailShield was different. eSIM op reis is essentially e-commerce. MailShield is a monitoring platform that needs to receive e-mail, parse XML, run checks against DNS, score domains, and present it all in a dashboard.

I chose Next.js as the framework. Not because I’m a seasoned TypeScript developer, but because it has a massive community and, honestly, because Claude Code knows it really well. That last part mattered more than I expected. I’m an infrastructure guy. I can navigate code, but I’m not a frontend developer by trade. Claude Code let me move fast on the parts I’m less experienced with, while I focused on the parts I know best: the e-mail protocols, DNS, and infrastructure.

Within a couple of days I had a solid basis: a working UI, DMARC report ingestion and not long after: domain scanning for SPF, DKIM, and DMARC, and a security score. From there it was iterations. Adding MTA-STS monitoring. Then TLS-RPT. Then BIMI. Then DNSSEC and DANE. Before I knew it, MailShield was monitoring eight protocols, which is more than most competitors cover.

The stack

This is where it gets fun if you’re an infra nerd.

The obvious choice for hosting a Next.js app would be Vercel, Fly.io, or Railway. But I’m an infra guy who runs his own Autonomous System. I have a Proxmox cluster with more IP addresses than I know what to do with. Using someone else’s platform felt wrong.

So I spun up a VPS on my own infrastructure using my own portal (that’s a post for another day) and installed Coolify on it. Coolify is a self-hosted PaaS. Point it at your repo and it handles builds and deployments. I configured it to pull from GitLab and build on every push to main. Push, build, live. That’s exactly what I needed. Simple to setup too. No spending hours troubleshooting CI/CD files. Coolify uses Nixpacks under the hood to figure out what a project is and build it accordingly.

For e-mail handling, both inbound and outbound, I’m using Postal. It’s self-hosted transactional e-mail that can fire a webhook to my app whenever it receives a new message. That’s perfect for processing incoming DMARC and TLS-RPT reports.

I host everything myself where I can. Not because it’s easier (it’s definitely not), but because I don’t want to depend on external services that can change their terms, raise their prices, or decide they don’t like you anymore. My infrastructure, my rules. And my fault if it breaks.

From hobby project to product

At some point, the feedback shifted from “cool project” to “this is already actually useful”. That’s when I started thinking about pricing.

Who would my users be? Small businesses with a couple of domains, IT teams managing ten to twenty, MSPs juggling hundreds. Each has different needs and different budgets. I went through multiple iterations of the pricing model before landing on a tier structure based on domains, team size, and e-mail volume.

The e-mail volume part was a deliberate choice. DMARC reports include the number of e-mails analyzed. Larger organizations send more e-mail, which means more reports and more data to process. Tying pricing partly to volume keeps it fair: a freelancer with two domains doesn’t pay the same as a company sending 100,000 e-mails a month.

I integrated Stripe for payments and built a free tier (2 domains, no credit card required). I wanted people to try it without friction. If the product is good enough, upgrades will follow.

What I learned

Claude Code changed the game for me. I would not have built this without it. Not because the code is magic, but because it removed the bottleneck. I could describe what I wanted, iterate on it, and ship features in hours instead of days. For a solo founder who’s stronger in infrastructure than frontend, that’s transformative.

Self-hosting everything is a competitive advantage, but it costs time. Every hour I spend on Coolify, Postal, or DNS configuration is an hour I’m not spending on features. But it also means my margins are excellent and I’m not locked into any vendor.

Building is the easy part. Getting people to find your product is harder. I’m still figuring this out. SEO, content, tool pages. It’s a different skill set from building infrastructure, and it doesn’t come naturally to me. But that’s the next challenge.

You don’t need to quit your job to build a SaaS. I built MailShield evenings and weekends while working full-time as a NOC Engineer. It’s not fast, but it’s sustainable. And having a steady income means you can make decisions based on what’s right for the product, not what pays the bills this month.

What’s next

MailShield is live, has a free tier, and covers more protocols than most tools in the space. The foundation is there. Now it’s about growth: more content, more visibility, and more users who discover that their e-mail security has blind spots they didn’t know about.

If you want to see where your domain stands, check your security score. It takes less than a minute, and you might be surprised by what you find. Who knows, it might actually help you ;).