CloneRadar
Detect systematic product exploration in trial accounts
Would you want to know if someone was systematically mapping your SaaS through a trial account?
I’ve been building CloneRadar around a simple observation:
A trial user who visits almost every feature, rapidly explores workflows and repeatedly tests different parts of your product might look like a highly engaged lead.
But they might also be mapping how your product works.
CloneRadar tries to identify those patterns and flag accounts worth reviewing.
The product is live, but I’m still validating whether founders actually care enough about this problem.
So I’m curious:
If you run a SaaS with a trial, would you want this visibility? And would you actually act on it?
Looking for a few SaaS founders to test it with.
Would you want to know if someone was systematically mapping your SaaS through a trial account?
I’ve been building CloneRadar around a simple observation:
A trial user who visits almost every feature, rapidly explores workflows and repeatedly tests different parts of your product might look like a highly engaged lead.
But they might also be mapping how your product works.
CloneRadar tries to identify those patterns and flag accounts worth reviewing.
The product is live, but I’m still validating whether founders actually care enough about this problem.
So I’m curious:
If you run a SaaS with a trial, would you want this visibility? And would you actually act on it?
Looking for a few SaaS founders to test it with.
7 Comments
The interesting test isn’t spotting unusual trial behavior, but whether it changes a founder’s decision. Have any testers actually changed how they handled an account because of a CloneRadar alert?
Fair pushback — that's exactly the right question to ask. Honestly, we're early: one active tester so far, and I don't have a case yet where an alert changed how someone handled an account. That's the whole point of this validation phase — detection is the easy part, proving it changes real decisions is what actually matters.
That's partly why I'd value having you on board — not just as a tester, but as someone who'll tell me straight whether an alert would've actually changed what you did with an account, or if it's just interesting-but-not-actionable noise.
The alert-to-decision gap is exactly what makes the validation interesting. If you’re open to it, what’s the best email to reach you on?
That gap is actually something we've already built for, not just thought about. On our Scale tier, a high-risk flag doesn't just sit in the dashboard — it fires a signed webhook with a recommended_action, so you can wire it directly into your own system (suspend, flag for review, whatever fits your flow) instead of relying on someone checking a dashboard. We deliberately don't take the action ourselves — no access to your auth system — but we make it possible to close that gap automatically if you want to.
That said, "possible to close it" and "someone actually did" are different claims, and I don't have a real case of the second yet — which is exactly why I want testers like you.
You can reach me at: contact@getcloneradardotcom
Cheers,
Dan
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
How do you separate systematic abuse from team testing on same wifi?
Is score visible to me or do you block silently?
Do you score at signup or after first 3-4 actions?
Good questions, here's how it actually works:
Team testing vs. abuse: CloneRadar doesn't score by IP/network — it's behavior-based (feature coverage in a session, event velocity, timing patterns, which areas get visited — e.g. broad feature sweep + API docs + pricing within minutes). Two people on the same office wifi testing normally won't trigger it, since normal exploration doesn't match the pattern. For known-good accounts (your own QA, internal testers), there's a whitelist so they're skipped entirely regardless of behavior.
Visibility: Never silent. CloneRadar only signals — it shows you the risk score and the evidence behind it in the dashboard, it never blocks or restricts anything automatically. What you do with that signal (review it, flag it, or wire up a webhook to react in your own system) is entirely up to you.
Timing: Scoring happens continuously as session events come in, not as a single check at signup — so it builds up as the session progresses rather than being a one-time snapshot after signup or after a fixed number of actions.
Let me know if you have more questions. Would also love to have you on board as an early tester — free during validation (30 days), and your feedback would shape the roadmap.
Cheers,
Dan