I Built My First Product as a Solo Developer — With Breaking Bad on My Second Monitor

Thu, 03 Sep 2026 19:33:43 +0000

A few months ago, I decided I wanted to ship my first real product.

Not another project sitting in a GitHub repository.
Not another prototype that works perfectly on localhost.
Something real. Something people could actually use.
That product became MailOnce.

And for a surprisingly large part of building it, my setup looked like this:

MailOnce on one monitor. Breaking Bad on the other.

Probably not the productivity system they teach you in engineering books.
But somehow, it worked.

Why temporary email?

I had used temporary email services before, mostly when testing signups, verification emails, and OTP flows.
They worked, but I kept noticing things that annoyed me, Sometimes messages took too long to arrive, Sometimes the interface was overloaded with ads and popups Sometimes I only needed a six-digit verification code, but I had to open the email and hunt for it.
And as a developer, I also wanted something that felt useful for testing email flows rather than just being a disposable inbox.

Eventually I had the dangerous developer thought:

"How hard could it be to build my own?"

Very hard, apparently.

Receiving an email is the easy part

At first, the idea sounded simple:

Generate a temporary address Receive an email and Display it.

Done.

Then the rabbit hole started.

I had to think about SMTP delivery, domains, inbox lifecycle, realtime updates, abuse controls, verification links, OTP detection, security, rate limits, responsive behavior, and what happens when multiple users are doing things at the same time.

Then there were all the problems that have nothing to do with the feature you're currently building.

A UI that looks perfect on your screen and breaks on another viewport.

A production configuration that behaves differently from local development.

An email that arrives correctly from one service but behaves differently from another.

A deployment where one missing environment variable can make a perfectly working feature suddenly look completely broken.

Building the feature was often only half the work.

Making it survive reality was the other half.

The feature I cared about most

One thing I really wanted was a better experience for verification emails.

If an email contains an OTP, MailOnce tries to detect it and surface it quickly.

If there's a verification link, the inbox should make that useful without forcing you to dig through a messy email.

And incoming messages should feel realtime.

These sound like small details.

But when you're testing the same signup flow again and again, small details become the entire experience.

Building solo changes the way you think

This was also my first product shipped as a developer.

That meant there wasn't another department waiting to solve the next problem.

Backend problem?

Mine.

Frontend problem?

Also mine.

Deployment?

Mine.

SEO?

Apparently mine too.

Production bug at the worst possible moment?

Definitely mine.

There were days where I spent hours fixing something users would probably never notice.

And there were other days where a tiny change made the whole product feel significantly better.

I learned that shipping a product is very different from finishing a feature.

A feature can be "done."

A product keeps finding new ways to tell you that you're not done.

And yes, Breaking Bad was actually there

This part isn't some clever metaphor for startup life.

I was literally watching Breaking Bad on my second monitor while working on MailOnce.

Sometimes I would spend an absurd amount of time debugging something, finally find the problem, look at the other monitor, and realize I had absolutely no idea what happened during the last 20 minutes of the episode.

So I would rewind.

Then go back to debugging.

Not exactly peak efficiency.

But it became part of the routine.

Today, MailOnce is live

After all the building, testing, breaking, fixing, deploying, and testing again, I finally reached the point where I was comfortable putting it in front of real users.

MailOnce is now live:

https://mailonce.org

You can generate a temporary email address and use it immediately. No account is required for the basic experience.

I also published a small developer repository with examples for testing things like OTP emails, signup verification, passwordless authentication emails, and verification links:

https://github.com/mailonce/mailonce-developer-kit

I'm still at the beginning.

There are things I want to improve, features I want to build, and probably bugs that real users will discover much faster than I ever could.

So if you're a developer, QA engineer, or just someone who uses temporary email:

Try to break it.

Seriously.

Send it weird emails. Test your verification flow. Use it on different devices. Tell me what feels slow, confusing, unnecessary, or broken.

I'd rather get useful criticism now than spend months building in the wrong direction.

And if you're building your first product too, here's probably the biggest thing this project taught me:

You don't really learn what your software is until you let strangers use it.

Now I get to find out what MailOnce actually is.