What changed
Per the convergence input (no underlying signal text was provided in this request, so this is taken from the hypothesis, not verified source text): Let's Encrypt withdrew its free certificate-expiry notification emails, removing the default renewal reminder for a very large installed base. Separately (inference), CA/Browser-forum pressure toward shorter certificate lifetimes makes manual expiry tracking progressively less viable.
Why now
If the Let's Encrypt notification shutdown is accurate, there is a time-boxed pain spike: operators who relied on those emails will experience their first silent lapses in the coming weeks/months, and outreach that arrives at the moment of a provable near-lapse lands with maximum credibility. The GTM window is the transition period before habits and competing reminders fill the gap.
Converging signals
(1) A free compliance-reminder layer disappearing for millions of domains [from convergence description; no source URL supplied]. (2) CT logs as a complete, public, machine-readable registry of every certificate, issuer, and expiry date — a free prospect database. (3) Trend toward shorter cert lifetimes increasing renewal frequency and failure surface [inference]. NOTE: the signals and demand_evidence arrays in this input were EMPTY, so none of these are independently evidenced here.
Customer pain
A lapsed certificate causes browsers to throw full-page interstitial warnings that destroy traffic, conversions, and trust — functionally an outage. SMBs discover it from angry customers; MSPs discover it from angry clients. HYPOTHESIS: the pain is episodic and existential when it happens, but invisible until it does, which historically makes monitoring a hard proactive sell and an easy reactive one — which is exactly why the 'we caught you mid-lapse' outbound angle is the interesting part of this idea.
Who pays
Primary: MSPs and web agencies managing 20-500 client domains (one buyer, bulk seats, recurring). Secondary: individual SMB site owners rescued mid-lapse. HYPOTHESIS: MSPs are the only segment where $10-30/mo aggregates into meaningful revenue; single-domain SMBs churn and are barely worth the support load.
Solved today
ACME auto-renewal (certbot/Caddy/managed hosting) handles the majority silently; for monitoring, free and cheap incumbents exist: UptimeRobot, Better Stack, StatusCake, crt.sh watches, Red Sift Certificates Lite, Keychest, plus SSL checks bundled into every uptime monitor. Cloudflare/managed hosts auto-manage certs entirely.
Why current solutions are bad
The incumbents monitor domains you tell them about — they require the operator to know they need monitoring and to set it up, which is precisely what the lapsed population failed to do. Nobody uses the CT registry to find the people currently failing and contact them at the moment of failure. The product's differentiation is the acquisition mechanic, not the monitoring feature, which is commodity.
Proposed product
A CT-log tailing service that (a) flags certificates expiring within 14 days with no successor cert logged for the same domain, (b) enriches with liveness + contact discovery (WHOIS, site scrape, MSP fingerprinting via NS/ASN/agency footer), (c) sends a factual, specific alert ('the cert for acme-widgets.com expires Friday 14:02 UTC; no renewal has been issued'), and (d) converts into ongoing monitoring: portfolio dashboard, Slack/email/SMS alerts, MSP multi-tenant view, white-label reports.
MVP version
A crt.sh/CT-tail pipeline + Postgres + a one-page report per lapsing domain + a Stripe-billed alerting dashboard. Genuinely 2-3 weeks of AI-assisted solo work; the founder has built harder scrapers. The REAL MVP is the falsification test in the convergence description and it costs almost nothing: run the CT diff for a week, count live domains lapsing with no successor, and cold-contact 100.
30-day build
Week 1-2: build CT diff + liveness filter; measure the addressable lapse population (the kill metric: if nearly all expiring certs show auto-renewed successors, stop). Week 3-4: contact-discovery pipeline; send 100 hand-reviewed rescue alerts; measure reply and conversion.
60-day build
If ≥2/100 convert per the testable prediction: productize the dashboard, add MSP multi-tenant + white-label, identify MSP-managed clusters in the lapse data (same NS/ASN across many lapsing domains = one MSP buyer with provable misses) and pitch those MSPs with their own client list as the demo.
90-day revenue plan
Target 10-20 MSPs at $50-200/mo (bulk domain packs) + long-tail rescued SMBs at $10-15/mo. Realistic 90-day revenue is low four figures MRR if the lapse population is real; this is a modest-ceiling product unless the MSP channel compounds.
Distribution path
The registry IS the distribution: provably-lapsing domains are a self-refreshing outbound list with built-in urgency and zero ad spend. Secondary: r/msp, r/sysadmin threads asking for Let's Encrypt reminder replacements (the convergence claims these exist — verify and post there), and a free single-domain tier as lead capture. Risk: scraped-contact cold email is spam-adjacent; deliverability and reputation management matter, and MSP fingerprinting partially mitigates by concentrating outreach on fewer, warmer targets.
Pricing hypothesis
$10-15/mo single domain (rescue conversions), $49-199/mo MSP tiers by domain count, white-label reports as the upsell. Per-rescue one-time fee ($25 'we'll fix it now' concierge renewal) is a plausible cash wedge at the moment of panic.
Technical difficulty
Low-to-moderate. CT logs are public and well-tooled (certstream, crt.sh); the hard 10% is contact discovery at acceptable accuracy (WHOIS privacy redaction guts naive approaches — expect heavy reliance on site-scraped emails and MSP inference) and email deliverability at volume.
Legal / regulatory risk
Low. CT data is public by design; monitoring is benign. CAN-SPAM/GDPR-compliant outreach needed (factual, opt-out, B2B). No government portal, no regulated data. The 'browsers as enforcer' framing is a metaphor — there is no actual regulator, which also means no actual mandate.
Platform dependency
Low. CT logs are a multi-party public infrastructure that cannot be revoked by a single vendor; crt.sh could rate-limit but direct CT-log tailing is the fallback.
Founder fit
Good but not top-tier. The pattern-match to his proven edge (public registry enumerates obligated parties → build the compliance layer → charge per obligation) is real, and the build is squarely in his scraping/automation/low-budget wheelhouse. BUT the applicable lesson (confidence 0.80) says government-portal MANDATE plays fit him best, and this is not one: browsers blocking a lapsed cert is enforcement without a filing requirement, so there is no submission layer to own and no per-filing toll booth — only commodity monitoring with a clever prospect list. Fit ~6-7, not 8-9.
Breakout potential
Moderate. The wedge generalizes: the same CT pipeline supports domain-portfolio hygiene for MSPs, subdomain-takeover detection, phishing-lookalike cert alerts, and M&A/asset-discovery data products. The monitoring product itself is a commodity with a low ceiling; the lapse-detection dataset is the reusable asset.
Final recommendation
CONDITIONAL GO on the test, HOLD on the build. This is a well-formed, cheaply falsifiable hypothesis with a genuinely clever acquisition mechanic, but demand_evidence is EMPTY — the Let's Encrypt shutdown claim, the 'sysadmins actively asking for replacements' claim, and all willingness-to-pay are unverified in this input. Run the one-week CT diff + 100-contact test (~2 weeks, near-zero cost, founder can easily fund). Kill without regret if lapse volume <500 live domains or conversions <2/100. Do not build the dashboard first.
Next action
Spin up a CT-log tail (certstream or crt.sh polling) today; after 7 days, count live-site domains with certs expiring ≤14 days and no successor cert logged, and verify contact discoverability on a 50-domain sample. Simultaneously verify the Let's Encrypt notification-shutdown claim against the official announcement.