Build Plan: ZipDock
● Live prototype This tool has a working CLI/web build you can try right now →Concept ZipDock — Archive Vault cluster, Vertical variant.
Summary
Look inside an archive someone sent you before you unpack it.
Archive managers barely evolved. Treat archives as secure portable workspaces with automatic safety checks.
Primary persona
The Specialist — a user in legal, finance, and operations teams exchanging sensitive archives, whose day-to-day workflow this variant is purpose-built around — not a generic power user.
Target customer (from research): legal, finance, and operations teams exchanging sensitive archives.
Competitive inspiration
We’re combining the strongest parts of tools people already pay for:
| Source app | Modeled annual revenue | Current stack |
|---|---|---|
| WinRAR | $8.0M | C++ native |
| WinZip | $12.0M | C++ native Windows |
| Folder Lock | $3.4M | C++ native Windows |
| O&O SafeErase | $2.0M | C++/.NET Windows |
Combined addressable revenue pool (modeled): $25.4M. Target capture rate: 6.6%.
Feature scope
v1 (MVP — ship this, nothing more):
- Archive
- Preview
- Encrypt
- Password vaulting
- Secure extraction
v2 (after v1 has real usage data):
- Secure delete
- Checksum verification
Architecture sketch
- Core engine: Rust archive/crypto engine
- Application shell: C#/.NET 10 WinUI 3 shell
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–3 | 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 4–10 | 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 11–14 | Polish, packaging & soft launch | Crash/usage instrumentation, code signing, pricing/licensing wiring, and a soft launch to a small user group. |
- MVP timeline: 9–14 weeks
- Build simplicity: 6/10 (higher = simpler)
- Opportunity score: 7.6/10
Go-to-market
- Partnerships and sponsorships inside the specific niche community
- Integrations / import-export support for the niche’s existing tools
- Targeted content marketing built around the specific workflow, not the category
- A referral program seeded through the niche community’s existing influencers
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 |
|---|---|---|
| Naming risk | The working name has a flagged trademark/domain collision and cannot be used as the shipping brand as-is. | Run a formal name-clearance pass (trademark + domain + store-listing search) before any public landing page, build, or store listing goes live. |
| 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 | Deeper OS/hardware integration (drivers, SMART data, low-level file APIs) adds real platform risk beyond typical CRUD app work. | Spike the riskiest OS integration point in week 1, before committing to the rest of the UI — kill or de-scope early if it doesn’t check out. |
Revenue scenario (modeled, not a forecast)
| Scenario | Estimated annual revenue |
|---|---|
| Low | $754K |
| Mid | $1.7M |
| High | $3.2M |
Pricing
$49–$149/yr depending value
Naming status
Working name only — brand verdict RENAME (Medium-High). Collision: ZipDock. Rename before investing heavily.
This is a working title for planning purposes. Clear the name (trademark + domain + marketplace search) before any public build, landing page, or store listing.
Build checklist
- Validate demand (forum/Reddit/community signal check for the archive vault 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.