What changed
FACT: FTC reports imposter-scam losses hit $3.5B in 2025, ~3x since 2020, inside a record ~$16B total fraud (+~25% YoY), dominated by fake 'it's us, pay now' messages. FACT: Meta's default use of public Instagram photos as AI material means anyone can generate convincing brand/person imagery from an @-mention, lowering the cost of a targeted impersonation run.
Why now
The raw material for impersonating a specific small brand (its public photos, voice, logo) is now free and one-prompt-away, while consumer losses to 'trusted-entity' impersonation are at record highs and rising — the gap between how easy impersonation is and how hard verification is has never been wider.
Converging signals
A platform signal (AI can clone any public brand instantly) meets a complaint/loss signal (record imposter-scam dollars). HYPOTHESIS: the overlooked buyer is the impersonated business, whose reputation and chargebacks are collateral damage — but this linkage is an inference, not evidenced by any complaint from a business willing to pay.
Customer pain
FACT (aggregate): consumers lost $3.5B to imposter scams. HYPOTHESIS (unproven): individual SMBs feel enough direct revenue/reputation loss from being impersonated to pay to stop it. The FTC data measures VICTIM loss, not impersonated-BRAND loss — the party who pays here is not the party shown to be harmed in the evidence.
Who pays
Intended buyer: SMBs/creators with a public brand and direct customer messaging (salons, clinics, boutique e-commerce, coaches). This is a discretionary buyer with no mandate and no deadline — willingness-to-pay is the entire risk.
Solved today
Platform 'verified' badges (Meta/Instagram blue check), the business posting 'we will never DM you for payment' in its bio, manual customer skepticism, bank/card chargeback processes, and consumer-side scam-detection apps sold to victims.
Why current solutions are bad
Badges verify the account, not an individual message or call; a bio disclaimer isn't checkable at the moment of a scam DM; and consumer-side tools require the victim to already be suspicious. But 'bad' does not equal 'someone will pay to fix it.'
Proposed product
Hosted verification microservice: each business gets a branded verify.link page + printable/IG-bio QR badge; a customer pastes a suspicious message or code and gets an authoritative 'this is us / not us' answer; optional signed-stamp on the business's legit outbound texts, and a customer-facing 'we will never DM you for payment' policy widget. Low monthly subscription.
MVP version
A single hosted page per tenant (business name, logo, a canonical 'how we contact you' policy, a paste-a-message check that returns not-us for anything requesting payment), a QR generator, and Stripe billing. Buildable solo in ~2-3 weeks on cheap infra.
30-day build
Build the verify page + QR + billing. Run the KILL TEST first, in parallel: cold-pitch 20 SMBs in impersonation-heavy niches (med-spas, boutique e-comm, coaches) for a paid pilot. Instrument whether ANY convert.
60-day build
If ≥2-3 pilots convert and their customers actually scan/use the page, add signed-message stamping and a simple 'report an impersonator' inbox. If zero convert in the first two weeks, stop — the impersonated party won't pay.
90-day revenue plan
Only if adoption is real: package by vertical, template the outreach, and add per-location pricing for multi-site franchises (salons/clinics). Target first recurring MRR from a narrow, hair-on-fire vertical rather than broad SMB.
Distribution path
Cold outreach to SMBs in high-impersonation verticals; vertical Facebook/Reddit groups; partnering with the POS/booking tools these businesses already use. Weakness: this is push-sales to a discretionary buyer with no urgency, the hardest distribution profile.
Pricing hypothesis
$15-49/mo per business; optional $99+/mo for multi-location or signed-stamping. Card-today billing, no procurement cycle.
Technical difficulty
Low. Standard hosted CRUD + QR + Stripe. Signed-message stamping adds mild complexity but is optional.
Legal / regulatory risk
Moderate-low: must avoid making false 'verified/safe' guarantees that create liability if a scam slips through; frame as informational, not a guarantee. No licensure required.
Platform dependency
Low for the core product (self-hosted, no platform can deplatform a verify page). But the PROBLEM lives on Meta/telecom channels the founder doesn't control, so the product can never intercept the scam message itself — it relies on the customer voluntarily leaving that channel to check.
Founder fit
Moderate. Buildable and micro-SaaS-shaped (fits his preference), but this is NOT the founder's primary thesis: no public-money flow, no forced-buyer/mandate, no government portal to file into. It depends on discretionary purchase AND end-consumer behavior change — the two things his strengths (public records, mandates, operational automation) don't de-risk.
Breakout potential
Modest. Could become a category if it rides a specific fraud-panic wave in one vertical, but the two-sided adoption requirement (business buys AND its customers use it) caps virality.
Final recommendation
WEAK PASS / VALIDATE-BEFORE-BUILD. Do the kill test (20 cold SMB pitches in 2 weeks) BEFORE writing meaningful code; treat a single paid pilot as the go/no-go. Off the founder's high-fit public-money/forced-buyer thesis, and the core demand claim conflates victim loss with brand willingness-to-pay — do not build on spec.
Next action
Run the 2-week kill test: cold-pitch 20 SMBs in one impersonation-heavy vertical (start med-spas or boutique e-com) for a $29/mo paid pilot with a one-page mockup — no product build until at least one converts.