Real-emails.com Series #1 – the plan

Defining what I’m going to build in the next 6 days

My deadline is 6 days away. If I want to make it, I have to have some sort of plan.
In this first update, I’ll take you through how I go from an idea to a plan.

The idea

Here’s a template I like to use to keep track of my ideas.
It’s very simple but helps me see more clearly where I want to go.

💡 One-sentence idea pitch

Real-emails.com is an API that lets you find out whether an email address is temporary/disposable or legitimate.

🤝 Value proposition

Collect email addresses you can trust

🗣️ Target audience

• Anyone accepting email addresses from their users who wants to make sure they’re not garbage

  • SaaS owners

  • E-commerce owners?

    • making sure customers register with a legitimate address

      • could make sense when you get 10% off your first order by subscribing to the store’s newsletter

  • Landing pages & lead magnets builders

  • Newsletter authors?

    • Probably newsletter platforms

  • Fintechs (disposable email = fraudsters)

💰 Business model

I see several possibilities here:

• Subscription (yearly/monthly)

• Pay-as-you-go with per-check pricing

• Lifetime deal

💬 Product description

• This is an API-first product—it’s meant for developers integrating email validation into their own products.

  • The « product surface » could ultimately be larger and include:

    • open-source API clients for various languages

    • platform plugins to provide plug & play integration with the service

• It’s quite simple: send an email address (or domain) through the API, and it will respond with a status (disposable or legit).

  • It might be interesting to have a bulk check feature too

⚙️ Resources

• Disposable email providers:

  • Google results for « temporary email », « disposable email », « burner email », …

  • disposable-email-domains GitHub repository
    → lots of domains are listed already, although 100% of recent Yopmail domains I have tested are absent.
    → Interestingly, they also have an « allowlist »

    • I could automate contributing back to that repo at some point!

My constraints

Before moving on to the plan, I think it's good in this instance that I outline my personal constraints. They will be key to gauge what I'll be able to deliver.

• I've got a job, so every weekday I can only work during the evening

  • That's 4 days out of 6 remaining

• On Saturday I'm going out with my son for his birthday!

  • Pretty excited about this as we’re going to Disneyland, but that means I actually have 5 days remaining to work on real-emails.com

Since I want to deploy something next Wednesday, I'm thinking:

• 🧑‍💻 Get the basic service done by Monday evening

• ⚙️ Deployment setup (server provisioning, domain config and so on) on Tuesday evening

• 🚀 Production deployment and troubleshooting on Wednesday evening

The job to be done

From my basic idea description, what I like to do next is make a list of what I have to build. I usually break it down into Proof of Concept, Prototype and MVP phases (with meanings that might be my own…).

As I've already done some technical validation that could be considered a Proof of Concept, I'll keep things simple here and merge Prototype/MVP into one phase.

Let's call it the Get it done! phase 😄

Get it done!

As you'll see, I try to be exhaustive and will list both the very basic & more complicated stuff.

I try to use my idea “brief” as an anchor to decide what's a 🟢 must have, i.e. key to execute on the value proposition, versus a 🟡 nice to have or a 🟠 maybe later.

So, here's what I have to build.

Build an API service

• 🟢 Basic JSON API

• 🟢 API authentication

  • 🟢 API key associated to subscribed user

• 🟠 API throttling & rate limiting

Identify disposable/temp email providers

• 🟢 Gather list of temp email providers

  • 🟡 Automatically update blocklist sources

  • 🟢 Identify their domains lists and dynamic features

    • e.g. Yopmail enrols new domains regularly, emailnator generates dummy Gmail addresses, etc.

• 🟢 Match provided email domain to blocklist

• 🟢 Dynamically identify provider domains in case of blocklist miss

  • e.g. detect a newly added Yopmail domain that hasn't made it to the list yet

  • 🟢 Cache results for faster lookups

• 🟡 Process & check emails in bulk

  • 🟡 Implement async processing

    • 🟡 with task API? (i.e. get task status/result)

  • 🟠 Implement webhook notifications

• 🟠 Allow flagging of false positives & false negatives

Let users subscribe & pay

• 🟢 User registration & authentication

• 🟢 Accept payments

  • 🟢 Activate API key on payment

    • 🟢 Implement payment webhooks

Provide integration tooling

• 🟡 API clients in different languages

  • JS, PHP, Python & Ruby at a minimum

• 🟠 Paid-for self-hosted solutions?

  • Could be a Docker image, a Rails engine, etc.

• 🟠 Platform integrations

  • 🟠 Blogs & Content management systems

  • 🟠 E-commerce platforms

---

Note: I usually use Notion toggles & databases to work on this – sorry if it's not very legible on the newsletter!

---

Bringing it all together

Given my constraints, I'll only be focusing on the 🟢 must haves for next Wednesday.

One of those tasks hides is an “infinite” source of work though: Dynamically identify provider domains in case of blocklist miss.
Indeed, it's going to be hard to cover all providers by Wednesday… if ever!

So I'm going to focus first on Yopmail and other providers found through Google searches that make use of the same DNS technique to add domains to their lists.

I'll keep Emailnator as a nice to have/maybe later, as their strategy is quite different and will probably prove harder to detect.

In terms of user authentication & payment, I found iffy.com’s approach simple and efficient:

1. Just provide your email address to log in – I'm not a fan of magic links so I might try to add Google/Apple login along with it, but for an API service it feels OK to me.

2. Once logged in, you get metered access to the API (3 calls per day) for free

3. If you want to subscribe, a click on “Pay for more” will bring you to a Stripe Checkout page to start your subscription

It's good inspiration but I'll make things much simpler to start with.
For instance, I think I will initially only implement a lifetime access deal. It will make since much easier regarding API key management, as I won't have to monitor recurring payment status to invalidate keys and so on.

So! Here comes the plan :)

• Tonight:

  • Project setup

  • User registration & authentication

  • API service with API key authentication

  • Endpoints specifications

• Sunday evening:

  • Blocklist matching implementation

  • Dynamic checks & results caching

• Monday evening:

  • Payment setup & implementation

• Tuesday evening:

  • Server provisioning

  • real-emails.com domain configuration

  • Deployment preparation

• Wednesday evening:

  • Production deployment

  • Live tests

See you on Sunday!