ScamMinder — AI Scam Detection Platform

A verdict that arrives late is not a verdict

ScamMinder answers one question: is this website a scam, asked by someone about to hand over money or personal information. What makes the product difficult is not the analysis — it is that the answer has value only inside a narrow window. A user standing at a checkout page will wait a few seconds. They will not wait a minute, and if they do wait, they have usually already decided. Accuracy delivered after the decision is indistinguishable from no answer at all.

That is why latency is not a performance concern here but the product requirement itself, and why the platform meets users where they browse rather than asking them to come to it. A web app serves the person who deliberately checks something. A Chrome extension serves the far more common case, where the question occurs mid-browse and nobody is going to open a second tab to ask it. A Telegram bot serves the moment a link arrives in a message, which is where a great many scams are first encountered.

Three surfaces for one question is not duplication. It is an acknowledgement that the decision point moves, and a tool that only exists in one place will be absent for most of the decisions it could have informed.

What the time budget forces

The pipeline runs fourteen phases and has to finish in seconds, which constrains the design more than any individual check does. Fourteen sequential phases with a few seconds of budget leaves each one a fraction of a second — an allowance too small to be useful when several involve network calls to external sources whose response times are not yours to control.

So the phases cannot simply queue behind one another. Anything independent has to run concurrently, which makes the slowest single phase the floor rather than the sum of all of them, and it means a phase that hangs cannot be allowed to hold the verdict hostage. In a fixed-budget pipeline the correct behaviour on a slow signal is to proceed without it and note its absence, because a slightly less informed answer delivered in time beats a complete one that arrives after the user has already paid.

Volume applies the second pressure. Past 20,000 domains, the cost and latency of re-running everything for a site already seen becomes the obvious thing to attack — domain-level results are reusable in a way per-user results never are, since the question "is this domain a scam" has the same answer for everyone asking it in the same period.

There is also an accuracy asymmetry worth being explicit about, because it shapes what the system should do when uncertain. A false negative fails the person the product exists to protect. A false positive accuses a legitimate business. Neither is acceptable, they are not symmetrical in consequence, and a tool that resolves that tension by being vague helps nobody — which is what makes how the verdict is produced the central design question rather than an implementation detail.

Separating signals from judgment

The architecture's defining decision is that the model does not look at a website and guess. The fourteen phases gather signals, and GPT-4o sits above them as a classification layer that turns those signals into a scam-risk verdict.

That ordering matters for four reasons. It is auditable: a verdict can be traced back to the specific signals that produced it, rather than to a model's impression of a page. It is consistent, because the same signals lead to the same classification instead of varying with how a site happened to be phrased that day. It is cheap and fast, since classifying a compact set of structured signals is a far smaller task than asking a model to browse and reason from scratch. And it degrades sensibly — when a phase fails to return, the classifier receives fewer signals rather than nothing at all.

It also puts the model where models are genuinely better than rules. Weighing a combination of weak indicators into a judgment is exactly the task a threshold-based rule set handles badly, because scam signals are individually unremarkable and only meaningful in combination. The pipeline is deterministic and the judgment is probabilistic, and keeping those two things in separate layers is what makes either of them improvable without disturbing the other.

The delivery surfaces sit on top of that same core. A web app, a Chrome extension, and a Telegram bot are three clients of one verdict, not three implementations of it — which is the only version of this that stays consistent as the pipeline changes. Stripe and PayPal cover payments, with two providers because a product sold internationally meets users whose preferred method is not universal.

What the numbers mean

Sub-6s analysis time is the figure the product is built around, and it should be read as a ceiling rather than an average. It is the promise the fourteen phases, the concurrency, and the classification layer all exist to keep — every architectural decision above is downstream of that number.

20,000+ domains analysed is the evidence that it holds outside a demo. A pipeline that finishes quickly on a handful of well-behaved sites proves very little; one that has processed that volume has met malformed pages, unreachable hosts, and slow third-party sources, which is where fixed time budgets usually break.

99.9% uptime carries weight for a reason specific to this product. A scam detector that is unavailable is not merely inconvenient — it is absent at exactly the moment it was supposed to be useful, and the user proceeds without it. For a tool whose entire value is being there at the point of decision, availability is not an operational statistic. It is the same requirement as speed, measured on a longer timescale.