How to Stop People Gaming Your Free Tier

You Built a Free Tier. Now Everyone Is Exploiting It.

You shipped a free tier because it is the right growth strategy. Let people try the product, get hooked, convert to paid. Textbook SaaS. Except now you are watching your Stripe dashboard and wondering why 2,000 new accounts signed up last week but your MRR did not move.

The answer: a significant chunk of those signups are fake. Bot operators, credential farmers, and freeloaders who will never pay you a cent. They are burning your compute, poisoning your metrics, and costing you real money every month.

So you start fighting back. And that is where most teams waste three months building the wrong defenses.

Why the Obvious Defenses Do Not Work

Every developer goes through the same sequence. I have watched it happen at four different companies. You try the obvious thing, it fails, you try the next obvious thing, and that fails too.

IP blocking. Your first instinct is to ban the offending IP addresses. Reasonable. Completely useless in practice. Residential proxies cost $3 per GB. Bot operators rotate through millions of IP addresses. You will spend more time maintaining your blocklist than they spend circumventing it. You are playing defense against an attacker with an unlimited supply of identities.

Email domain blocklists. Next you grab an open-source list of disposable email domains and block them at signup. This catches Mailinator and Guerrilla Mail. Great. There are over 945 known disposable providers, and new ones launch weekly. Your blocklist is stale the moment you commit it. Domain blocklists are whack-a-mole. You will never keep up.

Rate limiting alone. You add a rate limiter: 5 signups per IP per hour. The bots just slow down to 4. They are patient. They have scripts that sleep between requests and rotate IPs every few attempts. A rate limiter that does not bother the bots but occasionally locks out a corporate office sharing a NAT gateway is worse than no rate limiter at all.

CAPTCHAs. CAPTCHAs are theater. Solving services charge $0.003 per solve. Three tenths of a cent. AI vision models crack image challenges with over 90% accuracy. Meanwhile, CAPTCHAs cause up to a 40% drop in signup conversion for your real users. You are adding friction that stops humans and barely inconveniences bots. That is the opposite of what you want. We wrote an entire post about why CAPTCHAs are dead if you want the full picture.

Each of these defenses addresses one vector. Attackers use all of them simultaneously. Single-layer defenses plateau at about 60% effectiveness. That remaining 40% is eating your margins.

The Hidden Data in Every Signup Form

Here is what most developers miss: every signup request contains a dozen signals that you are throwing away. You collect the email address and maybe the IP, then move on. But that email and that IP are packed with information.

Email entropy. Real people choose email addresses that mean something: their name, a nickname, a hobby. The string john.martinez92 has a Shannon entropy around 3.2 bits. The string xk7qm3vb9 clocks in at 4.3 bits. That difference is statistically detectable and remarkably consistent. Humans are predictable in how they pick usernames. Bots are not.

Domain age. If the email domain was registered 36 hours ago, that tells you something. Legitimate companies and email providers have domains that are years old. A domain registered this week that is suddenly sending you 80 signups is not a promising startup. It is a credential farm.

MX records. Some domains do not even have mail exchange records configured. They literally cannot receive email. An address at one of these domains passes your regex validation and fails basic deliverability. You would be surprised how many fake signups use domains with no MX records.

Catch-all detection. Some domains are configured to accept mail for any address. Anything@sketchy-domain.com routes to the same inbox. That is a red flag. Legitimate mail servers reject addresses that do not exist. Catch-all domains accept everything, because they are set up for exactly this kind of abuse.

IP reputation. Is the signup coming from a residential ISP, a datacenter, or a known proxy network? AWS IP ranges, Tor exit nodes, and commercial proxy endpoints are all identifiable. A signup from a DigitalOcean droplet is not a real user.

User-agent analysis. Bots running headless Chrome have default user-agent strings and header orderings that differ from real browsers. Some do not even bother faking it. Others get close but miss subtle details like the order of Accept-Language headers or the presence of specific feature flags.

Each signal alone is inconclusive. A VPN user is not necessarily a bot. A high-entropy email might belong to someone named Xhevat Krasniqi. But when you combine six signals that each say "this looks suspicious," the composite picture becomes clear.

Building a Scoring System vs. Buying One

At this point you might be thinking: I can build this myself. You can. I have tried. Here is what the DIY path actually looks like.

First, you need a disposable domain list. You find one on GitHub with 600 entries. Within a month you discover 50 domains it missed. You start maintaining your own fork. Now you are a part-time threat intelligence analyst.

Next, you need SMTP verification. You set up a service that connects to mail servers and checks if mailboxes exist. Except Gmail rate-limits SMTP connections. Yahoo blocks them entirely after 10 attempts. Outlook returns false positives for nonexistent accounts 30% of the time. You spend two weeks building retry logic and provider-specific workarounds.

Then you need IP reputation data. You can query a free GeoIP database, but that does not tell you if an IP is a proxy or a datacenter. The databases that do cost $200 to $500 per month and still require you to build the lookup, caching, and scoring logic around them.

Now you need to combine all of this into a weighted score. What weight do you give each signal? How do you handle missing data? What thresholds do you use for block vs. review vs. allow? You do not know yet. You need weeks of production data to calibrate, and during those weeks the bots are still getting through.

The realistic timeline: 2 to 3 months to build something that works okay. And it never stops needing maintenance. New disposable domains. SMTP provider changes. IP database updates. Signal weight retuning. You have built yourself a second product that generates zero revenue.

Or you can call an API.

Integration: A Node.js/Express Signup Endpoint

Here is what it looks like to protect a signup endpoint with BigShield's validation API. This is a standard Express handler that checks the email before creating the account.

import express from 'express';

const app = express();
app.use(express.json());

app.post('/api/signup', async (req, res) => {
  const { email, password, name } = req.body;

  // Validate the email through BigShield before doing anything else
  const validation = await fetch('https://bigshield.app/api/v1/validate', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.BIGSHIELD_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      email,
      ip: req.headers['x-forwarded-for'] || req.socket.remoteAddress,
      user_agent: req.headers['user-agent'],
    }),
  });

  const result = await validation.json();

  // Use the fraud_decision field to gate signup
  if (result.fraud_decision === 'deny') {
    // Log it. You will want this data later.
    console.log(`Blocked signup: ${email}, score: ${result.score}`);
    return res.status(422).json({
      error: 'This email address cannot be used for signup.',
    });
  }

  if (result.fraud_decision === 'review') {
    // Let them in, but flag for manual review
    const user = await createUser({ email, password, name, flagged: true });
    console.log(`Flagged signup: ${email}, score: ${result.score}`);
    return res.status(201).json({ user: { id: user.id, email: user.email } });
  }

  // fraud_decision === 'allow' — clean signup
  const user = await createUser({ email, password, name, flagged: false });
  return res.status(201).json({ user: { id: user.id, email: user.email } });
});

That is the entire integration. One fetch call, one branching decision. The response from BigShield gives you everything you need to make the call.

Here is what the response object looks like:

{
  "email": "xk7qm3vb9@tempmail.plus",
  "score": 12,
  "fraud_decision": "deny",
  "verdict": "high_risk",
  "signals": {
    "disposable_domain": {
      "detected": true,
      "confidence": 0.99,
      "score_impact": -25
    },
    "email_entropy": {
      "detected": true,
      "confidence": 0.87,
      "score_impact": -15,
      "entropy_value": 4.32
    },
    "mx_records": {
      "detected": false,
      "has_mx": true,
      "score_impact": 0
    },
    "domain_age_days": 3,
    "ip_datacenter": {
      "detected": true,
      "provider": "DigitalOcean",
      "confidence": 0.95,
      "score_impact": -12
    },
    "catch_all_domain": {
      "detected": true,
      "confidence": 0.92,
      "score_impact": -8
    }
  },
  "latency_ms": 87
}

Every signal that fired is transparent. You can see exactly why an email scored the way it did, which signals contributed, and how confident the system is in each one. No black box. If a legitimate user gets blocked, you can trace the exact reason and adjust your thresholds or add a custom rule.

The "Why Not Both" Approach

The best setup is not either/or. Use BigShield as your primary gate and keep a simple rate limiter as backup. They solve different problems.

BigShield answers: "Is this signup likely legitimate?" It evaluates the email, the IP, the domain, the patterns. It catches the sophisticated stuff that rate limiting never will: disposable domains, algorithmically generated addresses, credential farms using fresh domains.

Your rate limiter answers: "Is this IP sending too many requests too fast?" It catches brute-force volume attacks that might overwhelm any external API call. Keep it simple: 10 signups per IP per hour. If someone hits that limit, they are not a normal user regardless of what their email looks like.

And log everything. Every signup attempt, every score, every decision. When you get a fraud spike next month (and you will), those logs are how you figure out what changed and how to respond. The teams that recover fastest from abuse incidents are the ones that can query their logs and see patterns within minutes.

A practical layered setup looks like this:

1. Rate limiter first. Cheap, fast, drops obvious volume attacks before they reach your validation logic.
2. BigShield validation second. Scores the email and metadata across 30+ signals. Returns a fraud_decision you can act on directly.
3. Logging third. Store the full response for every signup. Score, signals, decision, timestamp. You will need this for tuning thresholds and investigating incidents.
4. Manual review queue for edge cases. Signups that score in the gray zone (fraud_decision of "review") get created but flagged. Check these weekly. If 90% of your review queue turns out to be real users, raise your block threshold. If 90% is fraud, lower it.

This is not a "set it and forget it" system. You will tune thresholds over the first few weeks. But unlike maintaining your own domain blocklists and SMTP verification infrastructure, the tuning takes minutes per week instead of hours.

Stop Building. Start Blocking.

Every week you spend building homegrown fraud detection is a week the bots are still getting through. They do not wait for your sprint to finish. The math on DIY fraud prevention almost never works out, especially when you factor in the ongoing maintenance that never ends.

BigShield's full signal stack runs 30+ checks in under 100ms. The free tier gives you 1,500 validations per month, which is enough to protect a product doing 50 signups per day without spending anything. That covers most startups through their first real growth phase.

If free-tier abuse is already costing you more than you realize (and based on the numbers we have seen, it probably is), stop trying to solve it yourself with duct tape. Check the docs, grab an API key, and ship the integration in an afternoon. Your bots will not know what hit them.