What changed
FACT (source 1845/r-sysadmin): Let's Encrypt is discontinuing its free expiring-certificate email notifications, and its large installed base is actively hunting for a replacement. FACT (source 5775/HN): a Debian 12 update flipped MariaDB to systemd socket activation, silently making it listen on all interfaces (:::3306) instead of 127.0.0.1, exposing DBs to the internet without warning.
Why now
Two live, dated triggers this cycle: the LE email-notification withdrawal (admins asking 'what do I use instead?' right now) and a fresh silent-default regression hitting many servers at once. Both are the same emotional pain: 'my thing broke/got exposed and nothing told me.'
Converging signals
A withdrawn free safety net (cert-expiry alerts) + a class of silent OS-default exposures + turnkey metered billing (UnitPay) that lets a solo dev charge by card in hours. HYPOTHESIS: these are adjacent monitoring needs the same buyer will pay for in one bundle.
Customer pain
FACT (source 1845): sysadmins explicitly asking for a simple tool/script to monitor cert expiry and send alerts now that LE emails are ending. INFERENCE: fear of an outage from an expired cert or a breach from a silently-exposed port β both are 'career-damaging surprise' events, high anxiety, but also cheaply self-solvable.
Who pays
Solo sysadmins, indie hosters, small MSPs managing a handful of domains/servers with no enterprise monitoring stack. Discretionary buyer paying by card at signup β NOT enterprise procurement.
Solved today
Free/cheap incumbents: self-hosted Uptime Kuma (has TLS-expiry monitoring built in), certbot/ACME renewal logs, cron + openssl one-liners, Nagios/Zabbix, and free tiers of UptimeRobot/StatusCake/Better Stack. Port exposure: shodan/nmap run manually, or nothing.
Why current solutions are bad
Uptime Kuma must be self-hosted (another server that itself can go down and needs patching β the very thing a broke solo admin is trying to avoid). Renewal logs are silent until failure. Nothing in the free stack proactively flags 'a port that was 127.0.0.1-only is now world-reachable.' The port-exposure detection is the genuinely differentiated piece; cert-expiry alone is commoditized.
Proposed product
A hosted, zero-install watchdog: (a) TLS cert-expiry checks on a domain list with 30/14/3-day email+Slack alerts; (b) recurring external port scan that diffs against a baseline and alerts ONLY on newly-reachable DB/admin ports (3306/5432/6379/27017/9200/etc.). Simple dashboard, metered billing via UnitPay.
MVP version
Cron worker on a free tier: openssl-based cert expiry + a masscan/nmap external diff scan; alert via email + Slack webhook; a one-page dashboard; UnitPay for card billing at signup. Buildable in days to ~2 weeks.
30-day build
Ship cert-expiry alerts + port-exposure-diff for a hardcoded then user-editable domain/IP list; wire UnitPay; launch in the exact r/sysadmin thread and follow-ups, HN, and indie-hoster Discords with 'the LE-email replacement that also catches silent port exposure.'
60-day build
Add baseline auto-detection, Slack/Discord/Telegram/webhook outputs, per-account domain/server limits, and a free tier (3 domains) to drive signups; publish the Debian-MariaDB exposure story as content marketing.
90-day revenue plan
Convert free-tier and thread traffic to $9/mo paid; target a few hundred paying accounts. HYPOTHESIS (unproven): conversion is the risk, since the buyer can self-host the free alternative.
Distribution path
The originating r/sysadmin thread and its analogues, HN, indie-hoster/homelab/selfhosted communities, MSP subreddits, and SEO on 'Let's Encrypt expiry email replacement' and 'detect exposed MariaDB/port.' Content-led, no ad spend.
Pricing hypothesis
$7β15/mo per account (tiered by domains + servers), card at signup via UnitPay; free tier of ~3 domains as the acquisition wedge.
Technical difficulty
Low-to-moderate: TLS checks trivial; external port scanning is easy but needs rate-limiting, abuse controls, and a 'you must prove you own this host' verification to avoid becoming a scanning-for-strangers tool.
Legal / regulatory risk
Moderate and the main non-market risk: scanning IPs the user doesn't own can violate CFAA/ToS. MUST require domain/host ownership verification before scanning. No government-portal or platform-owner risk.
Platform dependency
None material β no app-store or platform gatekeeper. Depends on UnitPay for billing (swappable for Stripe).
Founder fit
Moderate. This is a discretionary quick-win, NOT the founder's primary public-money/forced-filer thesis β no mandate, no forced buyer, no appropriation. It suits his systems/automation/ops strengths and fast-prototyping, and is genuinely solo-buildable, but it lacks the structural forced-buyer demand where he scores highest.
Breakout potential
Modest. Could expand into a broader 'solo-sysadmin surface monitor' (DNS changes, expiring domains, open S3 buckets, new subdomains) β but every adjacency competes with an existing free or freemium tool.
Final recommendation
WEAK PASS / build only as a cheap experiment. Real, dated pain and a genuine differentiated angle (silent-exposure diffing), but the buyer is the most self-sufficient, least-willing-to-pay segment, free incumbents cover the cert half, and it's off the founder's high-fit public-money thesis. If built, lead with port-exposure detection (not cert alerts) as the wedge and validate willingness-to-pay in the r/sysadmin thread BEFORE building billing.
Next action
Post a concrete reply in the originating r/sysadmin thread offering a hosted cert+exposure monitor and a free-tier beta; measure how many ask for a paid version vs. say 'I'll just self-host Uptime Kuma' β treat <10 genuine paid-intent replies as a kill.