DEV Community: J Kelly

Week 1 of Launching EmailCheck.dev - What I Learned

J Kelly — Sun, 22 Mar 2026 15:41:14 +0000

Week 1 of Launching EmailCheck.dev - What I Learned About Zero to One
The unglamorous reality of launching a developer tool with no audience

TL;DR
Launched my email validation API a week ago. Posted on Indie Hackers and Dev.to. Got 50 visitors and exactly zero signups. Here's what I learned (and what I'm fixing).

The Launch Plan (That Didn't Work)
Last week I launched EmailCheck.dev - an email validation API that's 90% cheaper than NeverBounce ($9/mo vs $40/mo). I built it after getting a $487 bill from NeverBounce for my main SaaS.
My launch strategy was textbook indie hacker:

Post on Indie Hackers ✓
Write Dev.to article ✓
Share on Twitter ✓
Send DMs to founders ✓
Wait for signups ✓

Results after 48 hours:

Indie Hackers: 0 upvotes, 0 comments
Dev.to: 0 reactions, 0 comments
Twitter: Crickets
DM responses: 0
Beta signups: 0

Ouch.

What Actually Happened
I thought my posts would get buried because of bad timing or unlucky algorithms. But that wasn't the real problem.

The real problem: I have no audience.
When you post on Indie Hackers with 0 followers, you need engagement in the first 1-2 hours or the algorithm buries you forever. Same with Dev.to. Same with Twitter.

No followers → No early engagement → Algorithm thinks nobody cares → Post dies on page 5

I basically threw my launch into the void and expected it to echo back.

The Analytics Don't Lie
By day 3, I had 50 visitors total. Let me break that down:
Traffic sources:

Me checking the site: ~15 visits
A few random Twitter clicks: ~10 visits
Unknown (probably me on different devices): ~15 visits
Actual interested developers: ~10 visits

Conversion rate:

50 visitors → 0 signups = 0%

For context, a decent beta signup conversion is 10-20%. Even a terrible conversion rate is 2-5%.
0% means something is fundamentally broken.

The Form Friction Discovery
Here's the embarrassing part. My beta signup form asked for:

Name
Email
"What will you use it for?" (text area)
Twitter (optional)
Company (optional)

I thought this was reasonable. I wanted to know my users!

But here's what actually happens in someone's brain:

Sees form
"Name... okay"
"Email... fine"
"What will I use it for? Ugh, I have to write something?"
"Is my use case good enough?"
"This seems like work..."
[closes tab]

Form friction is conversion death.

Industry benchmarks:

1 field (email): 20-30% conversion
2 fields: 10-15% conversion
3+ fields: 2-5% conversion
My form: 0% (because even the 2% bounced)

I was literally asking people to write an essay to try my API for free.

The Wrong Traffic Problem
The 10-15 people who weren't me checking the site? They probably weren't even developers.

I posted on Twitter without any relevant hashtags. I DMed founders but sent them to my homepage instead of the beta page. I had no targeting, no strategy, just "post it everywhere and hope."

You can't convert visitors who don't have the problem you're solving.

A consumer seeing my site:
"Email validation API... what's an API? Eh, not for me." [leaves]

A developer who doesn't deal with signups:
"Email validation... I don't have this problem." [leaves]

A developer who uses NeverBounce and is happy:
"$9/mo is cheap but switching APIs is annoying." [leaves]

I needed developers who:

Have fake signup problems
Are currently paying too much
Are actively looking for solutions
Are willing to try new tools

That's maybe 0.1% of developers. No wonder I got zero signups from random traffic.

What I'm Changing
Fix #1: Email-only signup
Changed the beta form to literally just email. No name, no use case, no optional fields. Just:
[your@email.com]
[Get Free Access]

I can ask about their use case AFTER they sign up, in a welcome email. Or never, and just watch what they do with the API.

Fix #2: Target actual developers
Instead of posting everywhere, I'm focusing on:

Hacker News - Actual developers, chronological feed, everyone gets seen
Reddit r/webdev - Developers dealing with forms/validation
Dev.to with better tags - Using #api, #saas, #webdev, #showdev

Places where my target users actually hang out.

Fix #3: Lead with the pain, not the product
Old approach:
"Check out EmailCheck.dev - an email validation API!"
New approach:
"I got a $487 bill from NeverBounce last month. That's 25% of my revenue just validating emails. So I built my own for $9/mo."
Story first, product second. Nobody cares about features. They care about their own problems.

Fix #4: Build an engagement network
I reached out to 5 developer friends and asked them to:

Upvote my posts
Leave real comments/questions
Share if they think it's useful

Not fake engagement, but genuine help from people who want to see me succeed.
Early engagement = algorithm boost = more visibility = actual users see it.

What I Learned About Building in Public
The hard truth about launching with no audience:
You need to post the same thing 10-20 times across different channels, with different angles, over 3-4 weeks before something sticks.

Your first post will probably die.

Wrong time
Wrong title
No engagement
Algorithm buries it

Your second post will do better.

Better timing
Better title
A few upvotes from network
Maybe 10 signups

Your 10th post might blow up.

Perfect timing
Compelling story
Catches algorithm wave
Hits front page
500 visitors, 100 signups

Most people quit after post #2.
I'm on post #3. I need 7 more attempts.

The Technical Side (For Nerds)
Since this is Dev.to, here's what I built:
Stack:
.NET 10 API (yeah, I know, but it's FAST)
Fly.io hosting ($3/month)
MaxMind GeoIP for IP validation
Supabase for auth/database
Stripe for payments

API endpoint:
bashPOST https://api.emailcheck.dev/v1/validate
X-API-Key: your_key

{
"email": "user@gmial.com"
}

Response:
json{
"valid": false,
"email": "user@gmial.com",
"syntax_valid": true,
"mx_records_found": false,
"disposable": false,
"suggested_email": "user@gmail.com",
"confidence_score": 20
}

The hard parts:

Disposable detection (used GitHub's 10k domain list)
Typo suggestions (custom Levenshtein distance algo)
Rate limiting per API key
MX record caching (DNS lookups are slow)

The easy parts:

Syntax validation (regex)
Basic API structure
Stripe integration (surprisingly simple)

Current Status
Week 1 metrics:

Visitors: 50
Signups: 0
Lessons learned: Many
Times I wanted to quit: 3
Times I actually quit: 0

Week 2 goals:

Simplify signup form (email only) ✓
Post on Hacker News
Post on Reddit r/webdev
Get first 10 signups
Actually respond to feedback this time

Realistic timeline:

Week 1: 0-5 signups (learning)
Week 2: 10-20 signups (fixing conversion)
Week 3: 30-50 signups (momentum)
Week 4: 80-100 signups (beta full)

Not the overnight success I fantasized about, but achievable.

What I'm Still Figuring Out
Pricing:

Am I too cheap? ($9 vs $40)
Should I raise prices?
Or is cheap pricing my only advantage?

Features:

Do people actually need catch-all detection?
Is email health scoring (0-100) useful?
Should I build CSV bulk upload first?

Marketing:

Keep posting organically?
Try paid ads? (Reddit, Google)
Sponsor dev newsletters?
Just focus on making it really good?

Target market:

Indie developers? (they love cheap)
Small SaaS companies? (they need features)
Agencies? (they need white-label)
All of the above? (confusing positioning)

No idea. I'm making it up as I go.

The Unglamorous Reality
Building in public sounds sexy:

Daily progress tweets
Indie Hackers success posts
"Made $10k MRR in 3 months!" screenshots

But the reality is:

Posting and getting crickets
Refreshing analytics obsessively
Checking beta signups every 10 minutes
Getting exactly zero for days
Wondering if you should quit
Deciding to try one more channel
Repeat

Nobody sees the 47 posts that flopped.
They only see the one that hit front page.
I'm still on flop #3. Got a long way to go.

Want to Help?
If you made it this far, here's how you can help:
If you deal with user signups:
Try EmailCheck.dev for free. Tell me what sucks. I'll fix it.
If you've launched before:
What actually worked for you? I'm all ears.
If you just want to follow along:
I'm posting daily updates on Twitter @yourhandle.
And if you have literally any feedback - good, bad, brutal - leave a comment. Zero engagement is way worse than negative engagement.

Links

Beta signup: https://emailcheck.dev/beta (now just email, I promise)
API docs: https://emailcheck.dev/docs
GitHub (disposable domains): https://github.com/disposable/disposable-email-domains

Final Thought
Launching a product with no audience is humbling.
You think: "If I build something good, people will come."
Reality: Nobody will see it unless you make them see it, repeatedly, for weeks.
The difference between success and failure isn't the product.
It's whether you keep posting after post #7 gets zero engagement.
I'm on post #3. See you at post #10.

How I Stopped Worrying About Fake Signups (And Built an API Instead)

J Kelly — Tue, 17 Mar 2026 18:24:01 +0000

If you’ve ever built a signup flow, you’ve probably run into this at some point:

You launch something… and within a few days you start seeing signups like:

asdf123@mailinator.com
test@test.com
qweqwe@tempmail.xyz

At first I ignored it. Then it started affecting things:
noisy user data
wasted emails
skewed metrics
occasional abuse

That’s when I realized basic email validation wasn’t doing much.

Regex isn’t enough

Like most people, I started with a simple regex check.

It works for catching obvious mistakes, but that’s about it.
It doesn’t tell you:
if the domain exists
if the domain can receive email
if it’s a disposable address

So technically valid emails were still completely useless.

What actually helped
I started layering in a few additional checks.
Nothing fancy — just practical stuff that could run fast enough during signup.

Domain validation
Make sure the domain actually exists.
This alone filters out a surprising number of junk entries.
MX record check
Check if the domain can receive email.
If there are no MX records, it’s not going anywhere.
Disposable email detection
This made the biggest difference.

There are tons of disposable email providers, and once you start blocking those, a lot of low-effort spam disappears.

The tradeoff: speed vs accuracy

At one point I looked into SMTP-level verification (checking if the mailbox actually exists).

It works… but it’s slow.

And for a signup form, speed matters more than being 100% certain.

I’d rather:
let a few bad emails through
than slow down the signup experience for real users

So I focused on checks that are:
fast
reliable enough
easy to run in real time

What I ended up doing
After experimenting with this across a couple projects, I ended up wrapping these checks into a small API so I could reuse it.

The goal wasn’t to build something overly complex — just something simple that:

validates emails quickly
catches obvious junk
works well during signup

Example request:

POST /v1/validate
{
  "email": "user@example.com"
}

{
  "email": "user@example.com",
  "normalizedEmail": "user@example.com",
  "suggestedEmail": null,
  "valid": true,
  "confidenceScore": 90,
  "deliverabilityLikelihood": "high",
  "syntaxValid": true,
  "mxRecordsFound": true,
  "disposable": false,
  "roleBased": false,
  "freeProvider": false,
  "provider": "custom",
  "catchAll": false,
  "warnings": []
}

Where I landed
This setup has been a good balance so far:
fewer fake signups
cleaner data
no noticeable impact on signup speed

It’s not perfect, but it’s good enough for most real-world use cases.
Curious what others are doing
I’m interested in how others are handling this.

Are you:
sticking with basic validation?
using a third-party service?
doing anything more advanced?

Always curious to see how people balance accuracy vs performance here.

If anyone’s interested, happy to share more about what I’ve been building around this.

I'm looking for active developers to be Beta testers:

Join Beta Program - Get 50% Off Forever | EmailCheck.dev

Pro plan free for 3 months, then 50% off forever. Limited spots available.

emailcheck.dev

How I Stopped Worrying About Fake Signups (And Built an API Instead)

J Kelly — Sun, 15 Mar 2026 15:51:55 +0000

The $500/month wake-up call

Three months ago, I checked my SaaS expenses and nearly fell off my chair. NeverBounce was charging me $487 for the month. For email validation.

I run a small project management tool with about 15,000 users. Every signup, I validate their email to make sure it's real. Seems responsible, right? Well, at $0.008 per validation, those pennies add up fast.

The worst part? About 30% of my "validations" were just people mistyping their email on the signup form. I was literally paying money to tell users "you spelled Gmail wrong."

So I did what any developer does when they're annoyed: I spent a weekend building my own solution.

Why email validation matters (the hard way)

Before I was paying NeverBounce, I learned the hard way why you need email validation.

Week 1 without validation:

47 signups from tempmail.com addresses
23 from 10minutemail.com
Users creating accounts just to leave spam in comments
Support tickets from people who couldn't log in (they typo'd their email)

The breaking point:
One user created 150 accounts using mailinator.com addresses. Why? To spam our public roadmap with feature requests for cryptocurrency integration. Fun times.

So yeah, email validation became non-negotiable.

The "just use an API" trap

At first, using NeverBounce seemed smart:

// Simple, right?
const result = await neverBounce.validate('user@example.com');
if (!result.valid) {
  return res.status(400).json({ error: 'Invalid email' });
}

It worked! For about three months. Then my user base grew, my bill tripled, and I started looking for alternatives.

Alternatives I tried:

ZeroBounce - $0.008/validation (same price)
Hunter.io - Better pricing, but wanted me on annual contract
Kickbox - Great features, even more expensive

They're all good services. They're just... expensive for a bootstrapped side project.

Building my own (the technical bits)

I figured: how hard can email validation be?

Spoiler: Harder than I thought, but not impossible.

Step 1: Syntax validation (the easy part)

private bool ValidateSyntax(string email)
{
    if (string.IsNullOrWhiteSpace(email)) return false;

    var parts = email.Split('@');
    if (parts.Length != 2) return false;

    var local = parts[0];
    var domain = parts[1];

    // Basic checks
    if (local.Length == 0 || local.Length > 64) return false;
    if (domain.Length == 0 || domain.Length > 255) return false;

    // Regex for the nitty-gritty
    var regex = new Regex(@"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$");
    return regex.IsMatch(email);
}

This catches like 80% of garbage right away. Emails without @ signs, multiple @ signs, missing domains, etc.

Step 2: MX record verification (the actually useful part)

This is where things get interesting. You're checking if the domain can actually receive emails.

private async Task<bool> CheckMxRecordsAsync(string domain)
{
    try
    {
        var lookup = new LookupClient();
        var result = await lookup.QueryAsync(domain, QueryType.MX);

        var mxRecords = result.Answers.MxRecords();
        return mxRecords.Any();
    }
    catch
    {
        return false;
    }
}

This catches:

Typos like gmial.com (no MX records)
Made-up domains
Expired domains
Domains that can't receive email

It's not perfect (some domains have MX records but still reject mail), but it's pretty good.

Step 3: Disposable email detection (the pain point)

This is where I initially underestimated the problem.

Me: "I'll just hardcode the common ones"
Also me, 2 weeks later: "WHY ARE THERE 10,000 DISPOSABLE EMAIL DOMAINS"

My first attempt:

// Terrible idea, don't do this
private bool IsDisposable(string domain)
{
    var bad = new[] { "tempmail.com", "10minutemail.com", "guerrillamail.com" };
    return bad.Contains(domain);
}

This caught maybe 20% of disposable emails.

Better approach:
I ended up using the GitHub disposable domains list (https://github.com/disposable/disposable-email-domains). It's maintained by the community and has 10,000+ domains.

private HashSet<string> LoadDisposableDomains()
{
    var domains = new HashSet<string>(StringComparer.OrdinalIgnoreCase);
    var lines = File.ReadAllLines("disposable-domains.txt");

    foreach (var line in lines)
    {
        if (!string.IsNullOrWhiteSpace(line))
            domains.Add(line.Trim());
    }

    return domains;
}

Much better.

Step 4: Typo suggestions (the surprisingly useful feature)

This one came from user feedback. People kept emailing support: "I can't log in!"

Turns out, they typo'd their email on signup. gmial.com instead of gmail.com. Easy mistake.

I built a simple typo checker:

private string SuggestCorrection(string domain)
{
    var common = new Dictionary<string, string>
    {
        { "gmial.com", "gmail.com" },
        { "gmai.com", "gmail.com" },
        { "yahooo.com", "yahoo.com" },
        { "hotmial.com", "hotmail.com" },
        // ... etc
    };

    return common.GetValueOrDefault(domain);
}

Support tickets dropped by 40% after this. Worth it.

Making it an API (because why not)

Once I had it working for my own app, I figured: might as well make it an API.

Tech stack:

.NET API (I know, I know, but it's fast)
Fly.io for hosting (~$3/month)
Supabase for auth/database
Stripe for billing

Endpoint:

POST https://api.emailcheck.dev/v1/validate
Content-Type: application/json
X-API-Key: your_key_here

{
  "email": "user@gmial.com"
}

Response:

{
  "valid": false,
  "email": "user@gmial.com",
  "syntax_valid": true,
  "mx_records_found": false,
  "disposable": false,
  "suggested_email": "user@gmail.com",
  "confidence_score": 20,
  "warnings": ["MX records not found", "Did you mean gmail.com?"]
}

The pricing part (where I probably screwed up)

I wanted to make it stupid cheap. Like, "I would have used this instead of NeverBounce" cheap.

My pricing:

Free: 100/month
Starter: $9/mo (5,000 validations)
Pro: $29/mo (50,000 validations)

NeverBounce equivalent:

5,000 validations: $40/month
50,000 validations: $250/month

Yeah, I'm probably leaving money on the table. But honestly? I built this to solve my own problem. If other people find it useful and I can cover server costs, I'm happy.

What I learned

Things that were easier than expected:

Basic validation logic
DNS lookups
Building the API itself

Things that were harder:

Disposable email detection (there are SO MANY)
Edge cases (seriously, email specs are wild)
Pricing strategy (still not sure I got this right)

Things I'm still working on:

Catch-all detection (checking if domain accepts everything)
Email health scoring (is this a good email or sketchy?)
Better typo detection (using Levenshtein distance)

Try it yourself (the sales pitch, I guess)

If you're dealing with fake signups or paying too much for validation, I built this for you.

Quick integration:

Node.js:

const response = await fetch('https://api.emailcheck.dev/v1/validate', {
  method: 'POST',
  headers: {
    'X-API-Key': 'your_key',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ email: 'test@example.com' })
});

const result = await response.json();

if (!result.valid) {
  console.log('Invalid email');
}

Python:

import requests

response = requests.post(
    'https://api.emailcheck.dev/v1/validate',
    headers={'X-API-Key': 'your_key'},
    json={'email': 'test@example.com'}
)

result = response.json()
if not result['valid']:
    print('Invalid email')

PHP:

$ch = curl_init('https://api.emailcheck.dev/v1/validate');
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode(['email' => 'test@example.com']));
curl_setopt($ch, CURLOPT_HTTPHEADER, [
    'X-API-Key: your_key',
    'Content-Type: application/json'
]);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

$result = json_decode(curl_exec($ch), true);
if (!$result['valid']) {
    echo 'Invalid email';
}

The beta program thing

I'm looking for 50 beta testers to stress test this before I do a proper launch. If you sign up now:

Free Pro plan for 3 months ($29/mo value)
50% lifetime discount after beta
Direct Slack channel with me for support/feature requests

Interested? https://emailcheck.dev/beta

Wrapping up

Look, I'm not saying this will replace NeverBounce or ZeroBounce for everyone. They're great services with way more features than mine.

But if you're a solo dev or small team just trying to keep fake emails out of your database without spending $500/month, I built this for you.

Also, if you have ideas for features or find bugs, hit me up. I'm literally one person running this thing, so feedback is super valuable.

Happy validating!

Tech details:

API: .NET 10
Hosting: Fly.io
Database: Supabase (Postgres)
Payments: Stripe
Frontend: Vanilla JS (don't judge me)

Links:

Website: https://emailcheck.dev
Docs: https://emailcheck.dev/docs
Beta signup: https://emailcheck.dev/beta

Tags: #webdev #api #saas #email #validation #indie