← EraseProof

Build Plan: EraseProof

● Live prototype This tool has a working CLI/web build you can try right now →

Concept EraseProof — Privacy Eraser cluster, Pro variant.

Summary

Shred by policy on a schedule, and keep a ledger that proves it happened.

Cleaner products mix performance claims with privacy. Focus only on verifiable privacy cleanup and deletion.

Primary persona

The Power User — a technically fluent user who wants deep configuration, keyboard-driven workflows, and every advanced option the incumbent tools bury or omit.

Target customer (from research): Professional.

Competitive inspiration

We’re combining the strongest parts of tools people already pay for:

Source app Modeled annual revenue Current stack
O&O SafeErase $2.0M C++/.NET Windows
east-tec Eraser $1.7M Native Windows
Folder Lock $3.4M C++ native Windows
CCleaner Professional $18.0M C++ native Windows

Combined addressable revenue pool (modeled): $25.1M. Target capture rate: 6.6%.

Feature scope

v1 (MVP — ship this, nothing more):

  • Secure deletion
  • Privacy traces
  • Encrypted vault
  • Browser/app cleanup

v2 (after v1 has real usage data):

  • Proof-of-erasure report

Architecture sketch

  • Supporting component: Rust secure-delete/crypto core
  • Application shell: C#/.NET 10 WinUI 3

The split matters more than the exact tech: keep the engine (file I/O, hashing, scanning, capture — whatever is CPU/IO heavy) decoupled from the UI shell, so the engine can be tested headless and reused across variants in this cluster.

Roadmap

Phase Focus What happens
Weeks 1–2 Core engine spike Stand up the riskiest part of the tech stack first (the engine, not the UI) against real sample data and confirm the approach holds up.
Weeks 3–8 v1 feature build-out Build the full v1 feature scope below on top of the proven engine, wiring up the UI shell as features land.
Weeks 9–10 Polish, packaging & soft launch Crash/usage instrumentation, code signing, pricing/licensing wiring, and a soft launch to a small user group.
  • MVP timeline: 6–10 weeks
  • Build simplicity: 7/10 (higher = simpler)
  • Opportunity score: 7.9/10

Go-to-market

  • Power-user communities (Reddit, forums, Discord servers for the category)
  • Seeding review copies to YouTube / tech-reviewer channels
  • Head-to-head comparison pages versus the incumbent tools it replaces
  • Early-adopter lifetime-license pricing to build a vocal user base

Success metrics

  • Activation: % of installs that complete the core action (the thing in “Feature scope v1”) within the first session
  • Retention: 30-day active rate among installs that activated
  • Monetization: trial-to-paid conversion rate, tracking toward the $1.7M/yr mid revenue scenario within 12 months of launch
  • Quality: crash-free session rate ≥ 99.5% before removing the “beta” label

Risks & mitigations

Risk Why it matters Mitigation
Market risk Users already pay for the incumbent tools this concept borrows from and may see little reason to switch. Lead marketing with the specific market gap this product closes, not a feature checklist — differentiation is the pitch, not parity.
Distribution risk New, unsigned Windows apps routinely get flagged by SmartScreen or Store review, which kills first-run trust. Budget for a code-signing certificate and Microsoft Store review lead time before any public launch date is promised.
Technical risk The scope is largely straightforward app engineering; the main risk is time-to-polish, not feasibility. Timebox the v1 feature list tightly to the MVP scope below and resist adding v2 features before launch.

Revenue scenario (modeled, not a forecast)

Scenario Estimated annual revenue
Low $745K
Mid $1.7M
High $3.1M

Pricing

$49–$99 one-time or $39–$79/yr

Build checklist

  • Validate demand (forum/Reddit/community signal check for the privacy eraser job-to-be-done)
  • Clear the working name (trademark, domain, store listing collisions)
  • Spike the core engine described in the architecture sketch above
  • Ship a thin end-to-end MVP covering the v1 feature scope only
  • Instrument usage + crash reporting before wider release
  • Set up licensing/payment (one-time key or subscription per pricing direction)
  • Soft-launch to a small user group and gather pricing/feature feedback
  • Revisit the v2 feature list using real usage data, not guesses

Notes

Working product name only; validate trademarks/domains and user demand before build.