P0-01: Office Hours — Brutal Validation

Adversarial validation pass for mac-cleaner (“an honest macOS disk cleaner,” Swift 6 + SwiftUI, closed source, paid one-time, direct notarized distribution). Goal is to try to kill the idea, not confirm it.

1. The hard questions, answered directly

Why does anyone pay when PureMac and Pearcleaner are free and cover the same ground?

They mostly don’t, for the median user — and that’s the central problem this doc has to sit with.

• PureMac (momenbasel/PureMac): MIT-licensed, native SwiftUI, zero telemetry, ~5.6k GitHub stars, 314 forks. Pitched explicitly as “most Mac cleaning apps cost $30-50/year and collect usage data — PureMac does the same job for free.” Covers Xcode/Homebrew/system cache cleanup, scheduled auto-cleaning, signed and notarized builds. It is, feature-for-feature, close to a clone of what this product is scoped to be.
• Pearcleaner (alienator88/Pearcleaner): source-available, fair-code, Swift/SwiftUI, 11.3k–13.3k GitHub stars depending on the month measured (project site, OSS Insight-adjacent coverage). Covers app uninstall + orphaned-file hunting, a Homebrew manager, a dev-environment manager, PKG manager, services manager, and an updater — a superset of most “cleaner” scope, not a subset.

Both are free forever (MIT / fair-code), both are Swift-native (no Electron tax), and both already target the technically literate audience most likely to have real reclaimable junk. For a huge share of the addressable market, the honest answer to “why pay” is you don’t need to — PureMac or Pearcleaner already does the job.

Where a paid entrant can still win is narrower than “cleaning junk”: it’s the trust and maintenance gap underneath the free tools, which is real and sourced, not hypothetical:

• Pearcleaner’s own project status: the maintainer no longer has access to a Mac for personal development, so “issue responses, feature work, PR reviews, and new releases are effectively on hold indefinitely” (source). An 11k-star tool that does root-level deletion across your filesystem, with maintenance indefinitely stalled, is a legitimate opening — but only for buyers who notice and care. ESTIMATE: this is a small, security-literate sliver of the user base, not the median consumer.
• Pearcleaner ships a Homebrew manager, PKG manager, and services manager alongside the uninstaller — broader privilege surface than a buyer who wants only “clean my junk safely” may be comfortable running with elevated permissions.
• Neither free tool advertises a formal undo/quarantine step or a public, reviewable deletion-rules manifest — this repo’s stated design (“Never delete anything we cannot restore,” public rules/ manifest, per /Users/avantgarde/code/dfacto.ai/mac-cleaner/README.md) is a real product difference, not a marketing claim, if it’s actually built and if buyers value it over raw feature count. Neither of those is proven yet (see risky assumption #2).

Bottom line: there is no case for competing on feature breadth or price against PureMac/Pearcleaner. The only defensible pitch is safety/trust/maintenance-certainty for a narrow buyer who has enough at stake (proprietary work files, client data, a fleet of Macs) to pay for that certainty.

What does CleanMyMac’s ~$40/yr buy that we beat?

CleanMyMac (MacPaw) pricing as of mid-2026: ~$34.95–39.95/yr for one Mac, $54.95/yr for two, $89.95/yr for five; a lifetime one-time option exists at $89.95 for one Mac (MacPaw store via findstack.com, pricingnow.com). It bundles cleanup, malware scanning, “Smart Care” performance monitoring, and continuous background maintenance — i.e., it’s positioned as an ongoing subscription utility suite, not a single cleaning pass.

What we beat, if the “honest” positioning is real and delivered:

• No subscription treadmill — one-time price vs. an annual renewal that MacPaw is documented to increase over time. (source)
• No scareware UX — CleanMyMac’s category is widely criticized for inflating “issues found” counts and red-alert badges to drive renewal anxiety; this repo’s README explicitly bans that pattern (“No red badges, no ‘your Mac is at risk’”). This is a real differentiator if honestly executed, but it is also trivially copyable by a competitor repositioning their marketing copy — it is a UX/marketing claim, not a technical moat.
• No telemetry by default vs. CleanMyMac’s broader “Smart Care” suite, which is monitoring-first by design.

What we do not clearly beat: CleanMyMac’s malware scanning and continuous background maintenance are out of scope for a “cleaner,” so on raw feature count CleanMyMac still does more. The bet is that a meaningful slice of buyers actively want less — a single trustworthy tool that does one job and stops — not more.

Who is the buyer — general consumer or developer/pro?

This is the crux, and the two options trade off badly against each other:

• General consumer: low willingness to pay (PureMac/AppCleaner cover their actual reclaimable junk, which is usually small — old Photos caches, Trash, a few GB of logs), high support burden (macOS permission dialogs, Full Disk Access confusion, “why didn’t this find my files” tickets, refund requests when Mac isn’t meaningfully faster afterward — the classic “cleaner didn’t fix my slow Mac” support pattern that dogs the entire category). This buyer is also the one most exposed to CleanMyMac’s marketing budget and app-store discovery advantage.
• Developer/power user: has real reclaimable junk — Xcode DerivedData, iOS Simulator runtimes, node_modules sprawl, Docker images, Homebrew Cellar cruft, multiple SDK/toolchain versions — routinely tens of GB, sometimes 100GB+ per machine (directionally well-known in developer circles; no single authoritative “average GB reclaimed” study found, flagged as unverified magnitude, not unverified existence of the problem). Has money. But is also the exact audience most likely to already run brew cleanup, docker system prune, rm -rf ~/Library/Developer/Xcode/DerivedData, or Pearcleaner itself — i.e., the buyer with the most pain is also the buyer with the most free substitutes and the most technical confidence to self-serve.

Neither answer is clean. The developer/pro segment is the only one where the reclaimable value is large enough to justify a purchase decision on its own math, but it is also the segment hardest to convert away from free tools and command-line habits already in place.

2. Segment sizing

Segments below are not additive — they overlap heavily (a developer is also a “general Mac user”; a creative pro on a Mac fleet overlaps with IT/MSP). Total addressable market is bounded by the ~100M-Mac installed base, not the sum of the rows.

Reading the table honestly: only two rows (general users, developers) have real, sourced population numbers directly tied to Mac usage. The other three (creative pros, IT/MSP, resellers) are context, not sized markets — the research could not find authoritative Mac-specific numbers for them, and the product as scoped has no feature or go-to-market motion built for the two that would need one (fleet licensing for IT/MSP, secure-wipe workflow for resellers). Treat those as future option value, not part of the current business case.

3. Scored verdict

Overall: GO-WITH-CONDITIONS

Conditions: (1) do not target the general consumer as primary buyer — the free-tool substitution and support-cost math kill it; (2) prove the trust/safety pitch actually converts developer/pro buyers before investing past MVP (see falsification tests below); (3) do not build IT/MSP or reseller features until a sourced market size and a buyer conversation exist — right now those are narrative, not data.

4. The three riskiest assumptions

Assumption 1: “Developers with 50–500GB of reclaimable junk don’t already consider this problem solved.”

The pitch depends on developers having real pain and being open to paying a new tool to fix it. But this exact audience already has brew cleanup, docker system prune -a, manual rm -rf ~/Library/Developer/Xcode/DerivedData, and Pearcleaner’s dev-environment manager. Cheap falsification test: run a 20–30 developer survey/interview pass (r/macapps, dev Discords, Twitter/X) asking two questions only — “how do you currently clean dev junk?” and “would you pay $X once for a safer version of what you already do?” If >70% already have a satisfactory free workflow and see no gap, the segment’s willingness-to-pay is fiction and the plan needs to pivot before any more engineering spend.

Assumption 2: “The ‘honest / safe / undo-able’ positioning is worth paying for over a free tool that’s 90% as good.”

This is the entire viability and defensibility case, and it is currently untested — it’s a belief, not a finding. Cheap falsification test: ship a landing page today with the real one-time price, the actual “quarantine + undo + public rules” pitch, and a real “Buy Now” button (fake-door test, no product behind it yet, refund/waitlist on click). Post it where developers already are (Hacker News “Show HN,” r/macapps). If conversion-to-intent is near zero, or if comments consistently say “just use Pearcleaner,” the positioning does not clear the bar and the product should not be built as a general-purpose cleaner — pivot toward a narrower job (e.g., secure wipe-for-resale, or a fleet/IT SKU) where free tools don’t compete.

Assumption 3: “General consumers will pay and the support burden will be manageable.”

Even if the primary segment is developers, roadmap pressure will likely pull toward the much larger 100M-user general-consumer pool. That pool’s classic failure mode — buy, run once, “Mac isn’t faster,” refund/support ticket/negative review — is well-documented across the entire “Mac cleaner” review-site genre. Cheap falsification test: run a small paid beta (Gumroad or similar, 50–100 buyers sourced from a broad, non-technical channel, not a dev community) and measure refund rate and support-ticket volume per buyer in the first 30 days. A refund rate above roughly 15–20% (a reasonable red line for a one-time-paid utility, not a sourced industry benchmark — treat as a judgment threshold, not a fact) or heavy ticket volume confirms the general-consumer lane is a support-cost trap, not a revenue lane, and should stay explicitly out of scope.

5. Recommended primary segment

Developers / technical power users. One-sentence reason: it is the only segment where the reclaimable value is large enough (tens of GB of toolchain cruft) to make the purchase decision self-evident on the numbers alone, even though it is also the hardest segment to convert away from free tools — which is exactly why the product’s entire bet should be the safety/trust gap (Pearcleaner’s stalled maintenance, both free tools’ broad root-level privilege surface) rather than a feature-count race it cannot win.

6. Strongest argument against building this — stated at full strength

PureMac and Pearcleaner have already solved this problem, for free, forever. PureMac is MIT-licensed and Pearcleaner is fair-code/source-available — both are auditable, both are Swift-native (no Electron tax to point to as a technical excuse), and Pearcleaner in particular has a real, technically credible open-source community behind it (11k+ stars, 279+ forks) that has already shipped a superset of this product’s planned scope: app uninstall, orphaned-file hunting, a Homebrew manager, Xcode/dev-environment cleanup, a PKG manager, and a services manager. The marginal cost of the free product to the user is zero, its quality bar is already “good enough” for the exact segment (developers) with the most reclaimable junk and the most reason to buy, and Apple itself keeps closing the remaining gap by shipping more storage-management tooling directly into macOS every release. In a category where the incumbent free alternative is open-source, actively starred, and technically native, a closed-source, one-time-paid entrant’s only lever is “trust us more than the free thing” — a positioning claim, not a technical moat, and one that is trivially copyable the moment it starts working (any competitor, free or paid, can add an undo step and a public rules file). This isn’t a company; it’s a feature that Pearcleaner is one PR away from shipping, at which point the entire premise disappears.

Honest response

This argument is largely correct on features and mostly correct on cost structure — it should not be dismissed. Three things keep it from being fully dispositive, but none of them is proven yet, which is exactly why this is GO-WITH-CONDITIONS and not GO:

1. The trust gap is real and currently sourced, not hypothetical. Pearcleaner’s maintainer has lost personal Mac access and its development is “effectively on hold indefinitely” as of the most recent coverage found — an 11k-star tool doing root-level filesystem deletion, with maintenance stalled, is a genuine current opening, not a hedge. But this is fragile: a new maintainer or a community fork could close it overnight, so it cannot be the durable thesis — only the current wedge.
2. “One PR away” undersells how hard trust-by-default is to retrofit. Adding an undo feature to Pearcleaner is easy; making quarantine-by-default, no-scareware, and a public reviewable rules manifest the actual operating discipline of a project with an open contributor base and scope-creeping feature list (Homebrew, PKG, services managers) is a much larger, ongoing commitment that free OSS projects have historically been slower to sustain than to bolt on once. That said, this is an argument for why it’s possible to differentiate, not evidence that buyers will pay for it — which is precisely assumption #2 above and remains unproven.
3. The response is a hypothesis, not a rebuttal. The counter-argument only holds if the falsification tests in section 4 come back positive. If the landing-page fake-door test shows developers shrugging and saying “just use Pearcleaner,” the argument against building this wins outright, and continuing past that signal would be building for the sake of building — exactly the failure mode this document exists to catch.