So I finally shipped something I actually use every day.
It started as a personal annoyance. Every time I was testing a signup flow on a side project, I'd burn through fake email addresses, clutter my real inbox, or spend time creating throwaway Gmail accounts. After doing that maybe fifty times I thought, why not just build the thing I actually want.
The result is instanttempemail.com. A disposable email tool. No signup, no configuration. You open it and you already have an inbox waiting for you.
What I used to build it
The frontend is Next.js. I wanted fast page loads and a clean experience without unnecessary complexity. Next.js gave me what I needed there without fighting me.
The backend is Go. This was the part I was most deliberate about. Disposable email involves real-time inbox updates, handling SMTP, and serving a lot of short-lived sessions. Go handles concurrency cleanly and the performance is genuinely good. I'm not fighting the runtime to do what I need.
The two talk to each other over a simple API. Nothing exotic. The interesting engineering is mostly on the mail handling side, making sure messages arrive fast and the inbox feels alive.
I want you to actually test it
Here's the thing. I've been using it myself for months but there's a limit to how much one person can stress test their own tool. So I'm putting it in front of developers who will actually poke at it.
Go to instanttempemail.com right now. You'll get a temporary email address instantly. Then do something with it:
Send an email to it from your real account and see how fast it arrives. Use it to sign up for some service you've been curious about but didn't want in your inbox. If you're a developer, test your own signup flow with it. Drop the address into a newsletter you've been on the fence about.
Then come back here and tell me what happened. Did it work? Did it feel slow? Did something break? I genuinely want to know.
Why Go for the backend specifically
A few people have asked why not just use Node for the whole thing since I'm already in the JavaScript world with Next.js.
Honest answer: I wanted to write the backend in something that made me think differently about the problem. Go's approach to goroutines made the concurrent inbox handling feel natural in a way that async JavaScript sometimes doesn't. When you're dealing with incoming mail events and multiple users polling for new messages at the same time, having lightweight threads that don't require a lot of ceremony is genuinely useful.
Also I just like writing Go. It's fast to compile, easy to deploy, and the standard library covers a lot without pulling in a pile of dependencies.
What I'm still working on
Custom address prefixes are something I want to add. Right now addresses are randomly generated. Some people want to pick something memorable.
Longer inbox lifetimes for certain use cases. Right now sessions are short by design, but there's a reasonable case for optionally extending them.
Attachment previews. Currently you can see email content but attachments are limited. That's next on the list.
If any of those sound like things you'd use, let me know in the comments. It shapes what I prioritize.
The actual ask
Open instanttempemail.com, do something real with it, and leave a comment below. Doesn't have to be long. Even just "worked fine" or "this broke" is useful data.
I built this to scratch my own itch but I'd rather it be useful to more people than just me. The only way to know if it actually is, is to have real people try it.
Top comments (0)