How Much Are Fake Signups Actually Costing Your SaaS?

Your free tier might be costing more than you think. Here's how to calculate the damage, spot suspicious usage, and protect your product without making signup harder for legitimate customers.

Free tiers are great for growth. They let people try your product before committing to a subscription.

But what happens when someone starts creating hundreds of accounts just to collect your free credits?

If you're building an AI SaaS, an API product, or anything that gives new users access to paid infrastructure, those accounts can quickly become expensive.

I ran into signup abuse myself. It's one of the reasons I started building Chitmark.

The frustrating part isn't necessarily the fake signups. It's paying for usage that never had a realistic chance of turning into revenue.

Before adding more CAPTCHAs or forcing everyone to enter a credit card, there's a question worth answering:

How much is the abuse actually costing you?

Let's work through it.

1. Your free credits aren't actually free

Suppose you're building an AI-powered SaaS product.

Every new account gets 100 free credits. Users spend those credits generating content, processing documents, or making AI requests.

Those actions cost you money through model inference, compute, storage, or third-party API calls.

For this example, assume:

• Every signup receives 100 credits.
• Each consumed credit costs your business $0.025.
• An account suspected of farming consumes an average of 80 credits before becoming inactive.
• Those accounts generate no revenue.

The cost per account is:

80 credits × $0.025 = $2.00

Two dollars doesn't sound particularly concerning.

But look at what happens when the number of abusive accounts grows.

These are hypothetical figures, not Chitmark customer results. Replace the assumptions with your actual usage and infrastructure costs.

Now imagine dealing with this every month.

And this is only the direct usage cost. It doesn't include support time, investigating suspicious accounts, or the effect on your analytics.

Your signup dashboard might show impressive growth while an increasing share of those accounts never becomes a customer.

2. Calculate your real cost, not your advertised credit value

Here's a mistake that's easy to make.

If you advertise "$10 in free credits," that doesn't necessarily mean every free signup costs you $10.

The advertised value of your credits and the underlying cost of serving them are different.

What matters is how many credits people actually consume and what those credits cost your business.

A useful starting formula is:

Free-tier usage cost = Credits consumed × Internal cost per credit

For suspected abuse, use:

Suspected farming cost = Credits consumed by flagged accounts × Internal cost per credit

If your pricing isn't based on credits, use the underlying units instead: model tokens, compute seconds, API calls, or another metered resource.

For example, if an external AI provider charges you for input and output tokens at different rates, calculate those costs separately rather than assuming every request costs the same.

Use your marginal infrastructure and provider costs, not what you charge customers.

Also distinguish between the cost of credits granted and credits consumed. Issuing a credit doesn't necessarily create an expense until the user spends it.

You want to measure actual burn, not just theoretical exposure.

3. How do you know which signups are abusive?

This is where things get harder.

A suspicious signup isn't necessarily a fake signup.

Someone using a VPN could be a legitimate customer. Multiple users might share an office IP address. A developer testing your API could make hundreds of requests without doing anything malicious.

Blocking everyone who looks unusual is an easy way to lose customers.

Instead, start by looking for patterns across accounts.

Some useful signals include:

• Multiple accounts created within a short period.
• Accounts consuming most of their free credits shortly after signup.
• Repeated email-domain, network, or signup-timing patterns.
• Groups of accounts with similar usage behavior.
• High credit consumption with little meaningful product engagement or subsequent conversion.

None of these signals proves that someone is abusing your product.

But when several appear together, they give you a reasonable place to investigate.

The important distinction is between detecting suspicious patterns and proving abuse.

You shouldn't treat every flagged account as fraudulent.

4. Measure suspicious usage using your existing data

You don't need to integrate a new fraud-prevention service just to understand whether you have a problem.

Start with data you probably already collect.

At minimum, you'll need two datasets.

Signups

Usage

Illustrative rows only. The Chitmark baseline's signup export also requires an ip column.

Join the two datasets by user_id.

From there, you can answer questions such as:

• How many credits does a new account consume in its first 24 hours?
• What percentage of free-tier costs comes from accounts that never convert?
• Are there clusters of accounts registering around the same time?
• Do flagged groups consume credits differently from ordinary users?
• How much money is associated with the suspicious groups?

You can start with SQL or a spreadsheet.

If you'd rather use a ready-made tool, we've published a free credit-farming baseline at Chitmark.

It includes Python and TypeScript scripts that analyze signup, usage, and optional conversion exports locally.

For the Python version, download farming-baseline.py, prepare the CSV files using the documented schema, and run:

python3 farming-baseline.py --signups signups.csv --usage usage.csv --credit-cost-usd 0.025 --out summary.json

Replace 0.025 with your own cost per credit.

The script identifies suspicious cohorts and estimates their associated credit burn. Its output includes aggregate cost and pattern breakdowns rather than individual user records.

The scripts run offline, and nothing is enforced during this analysis.

That makes this a useful first step: you can investigate the potential cost without changing your production signup flow.

Remember that the resulting figure is an estimate of spending associated with flagged cohorts, not a confirmed total of fraudulent activity.

5. Why CAPTCHA and rate limits aren't enough on their own

CAPTCHA, email verification, and rate limiting are useful protections.

They help stop automated requests, reduce spam, and prevent individual accounts from consuming unlimited resources.

But they answer different questions.

A CAPTCHA asks whether a visitor can complete a challenge.

A rate limit asks how frequently a client can perform an action.

Neither necessarily answers whether several valid-looking accounts are being used to farm the same free grant.

Someone who successfully registers an account might still consume the free credits and create another account later.

And limiting every account to 100 credits doesn't solve the problem if one person can repeatedly obtain new accounts.

This is why it helps to protect the actions that create real costs.

That might be:

• Activating a trial.
• Issuing free credits.
• Creating an API key with complimentary quota.
• Starting an expensive AI generation.
• Unlocking a paid external API operation.

The signup endpoint is one possible checkpoint, but it isn't the only one.

These protections should complement your existing authentication, CAPTCHA, and rate limits rather than replace them.

6. Protect expensive actions without blocking everyone

Once you've established that suspicious usage is costing meaningful money, the next step is deciding what to do.

A simple rule-based system might let everyone through or block anyone who crosses a threshold.

But those aren't your only options.

A more flexible approach uses three decisions:

Allow: The request can proceed normally.

Challenge: There's enough uncertainty to justify an additional verification step.

Deny: The request shouldn't proceed under the applicable policy.

For example, someone signing up from a new network isn't necessarily suspicious.

But an account that matches several concerning patterns might be asked to complete an additional verification step before receiving a costly free grant.

The objective is to increase the cost of abuse without creating unnecessary friction for genuine users.

This is the approach behind Chitmark.

Chitmark provides an API that returns an allow, challenge, or deny decision before selected actions proceed.

You can call it before signup, trial activation, or API-key issuance. The application then handles the decision and any required challenge.

Chitmark also supports recording outcomes through its feedback API, so you can connect decisions to later events such as credit consumption or conversion.

If you're considering a verification layer, start in observation-only mode and compare decisions against actual outcomes before enabling enforcement.

And remember: a challenge must be completed and the action re-verified before proceeding. Issuing a challenge alone doesn't authorize anything.

7. Don't optimize away your paying customers

Suppose your current rules identify ten suspicious accounts.

You block all ten.

Later, you discover that three of those accounts belonged to legitimate users, and one would have become a paying customer.

You may have prevented some abuse, but you also introduced a cost to your acquisition funnel.

That's why counting blocked signups isn't enough.

Track both sides:

Your goal isn't to block the largest number of accounts.

It's to reduce unnecessary spending while keeping the free tier useful for people who might become customers.

That means reviewing outcomes, testing thresholds, and being willing to reduce enforcement if the false-positive cost is too high.

8. When should you actually invest in prevention?

Not every SaaS business needs an advanced verification layer.

If your free tier costs almost nothing to serve, or you only receive a handful of signups each week, adding another dependency might not make sense.

Start by measuring your exposure.

If suspicious cohorts account for a significant amount of spending, and those accounts consistently fail to convert, you have a stronger reason to investigate.

If the cost is negligible, basic rate limiting and existing protections may be sufficient.

Either result is useful.

Before investing in more protection, you should be able to answer three questions:

1. How much are suspected farming accounts costing us?
2. How confident are we that these patterns represent abuse?
3. Can we reduce that cost without hurting legitimate customer conversion?

Those answers will tell you whether prevention is worth the effort.

Final thoughts

A free tier should help people discover your product.

It shouldn't quietly become an unlimited subsidy for someone repeatedly creating accounts.

But removing your free tier or making every user enter a credit card isn't always the answer.

Start with the economics. Measure how your free credits are consumed. Identify suspicious patterns. Then add protection at the points where requests create real costs.

You may discover that the problem is small.

Or you may find that a meaningful share of your infrastructure bill is coming from accounts that never had any intention of paying.

Either way, having the numbers is better than guessing.

Want to see what your free tier is actually costing you?

Try Chitmark's free credit-farming baseline to analyze your own signup and usage data locally.

Or explore Chitmark if you're ready to add allow, challenge, or deny decisions before expensive actions.

Further reading: OWASP's Bot Management and Anti-Automation guidance, including its guidance on fake account creation and layered defenses.