SSD write-wear tracker for OS/app betas
Problem
People installing OS and app betas (and even AI coding agents like Codex) have no way to know how much excessive logging is wearing out their SSDs before it's too late. One commenter reports a work laptop at ~70% health with >700TB written, largely from endpoint-security logging. Everyone is left checking SMART counters manually with no shared, public data.
Opportunity
A 'Downdetector for disk writes': a lightweight local agent that attributes write volume per app/process over time, plus a public crowd-sourced dashboard comparing SSD wear across beta versions, so users can decide whether installing a beta is worth the wear and devs get shamed into fixing excessive logging.
Market analysis
A real, quantifiable pain with no dedicated tooling: SMART utilities report whole-drive wear, but nothing attributes writes per process or compares wear across beta versions. The local agent is a tractable MVP; the crowd-sourced dashboard is both the actual product and the actual risk.
Market · Power users, beta testers and IT admins; niche but vocal, with documented demand on HN and in Apple-silicon SSD-wear threads.
Pricing · Comparables are free (CrystalDiskInfo, vendor utilities); realistic path is freemium with a paid team/IT dashboard.
Pros
- + Genuine, recurring pain with vivid horror stories (700TB written from logging).
- + Local MVP is feasible with OS-level per-process I/O counters.
- + Public per-beta wear data has a built-in shaming/viral loop.
Cons
- − Crowd dashboard cold-start: it is useless until enough beta testers report.
- − Per-process I/O bytes are not the same as NAND wear; translating them needs per-drive TBW models.
- − Cross-platform attribution (Windows vs macOS APIs) is non-trivial.
Existing / similar tools
Source
Hacker News (Ask HN)
The gap is narrower than it looks: SMART tools already answer “how worn is my drive”, and OS utilities loosely answer “which process is writing”, so the missing piece is the join over time plus the public comparison layer. The local agent is a weekend project; the moat is the dataset, and the dataset only exists if beta testers adopt the tool in the narrow window when they care (right after installing a beta). That timing dependency makes growth lumpy: spikes at every major OS beta cycle, silence in between.