BlockVault — automatic backup, sync, restore & versioning for Minecraft worlds

[don-petry]

Problem

Kids sink hundreds of hours into Minecraft Bedrock worlds that live in a single fragile on-device folder. A new phone, a cracked screen, or a bad update wipes them — there's no undo, no history, and no simple device-to-device move. Phone-transfer tools (e.g. Samsung Smart Switch) often copy the data in a state that corrupts and crashes the game. Realms is paid hosted multiplayer, not preservation of a player's local world library.

Why now: Bedrock is ubiquitous on cheap/hand-me-down kid devices, cloud storage is cheap, and we've just proven the migration mechanics firsthand — 232 worlds moved S22→S24 by hand, which took ADB + a Chromebook + most of a day. Most families just lose the worlds instead.

Target user & JTBD

• Primary user: young Bedrock players (~7–15) on phones/tablets.
• Buyer: their parents (already pay for photo backup / device insurance / peace of mind).
• Secondary: map creators & streamers (versioned saves), Minecraft Education classrooms.

JTBD: "When I get a new device or a world corrupts, help me keep every world I've built — and let me rewind to an earlier save — without any technical work."

Rough impact / effort

• Impact — high. Strong emotional pull + clear willingness-to-pay; freemium → Family subscription (~$5/mo). Huge young-player TAM.
• Effort — medium/high. The moat and the risk is platform storage: Android 11+/iOS forbid one app reading another app's private storage. Proposed tiered access model — zero-setup .mcworld share-sheet baseline (everyone), Shizuku (ADB, no root) "power mode" for automatic full-library backup, desktop companion for big migrations, official Mojang API as the long-term holy grail.
• Rough ICE gut-check: Impact 5 / Confidence 3 / Ease 2 — attractive pull, real technical + legal unknowns to retire first.

Open questions

• Does the Mojang EULA permit third-party backup of user-created worlds? Trademark-safe naming?
• COPPA / GDPR-K: compliant architecture for storing minors' content + parent-consent flows.
• Can Shizuku power-mode onboarding be made genuinely parent-proof? (biggest conversion risk)
• Is the .mcworld share-sheet baseline durable as OS storage rules keep tightening?
• Market/positioning: how much "doesn't Realms already do that?" confusion to overcome?

---

Concept brief (private, richer): https://claude.ai/code/artifact/2af6d5ab-71e8-44f2-8647-6e44fb8ebe9b — working name "BlockVault". Captured from a real S22→S24 world-migration exercise (2026-07-12).

[don-petry]

Early POC evidence — 1 customer (n=1)

Before capture, the core mechanic was already validated hands-on for a real user — a kid's phone upgrade (Galaxy S22 → S24, 232 worlds). The full loop works end-to-end:

• Backup: entire local world library captured and uploaded to the cloud (Google Drive), integrity-verified (md5).
• Restore: all worlds restored and confirmed loading on the new device — no cables-for-the-user, no corruption.
• Failure mode understood: reproduced the crash the naïve path (Samsung Smart Switch) causes, and isolated the exact in-scope vs. must-skip file set that yields a clean, working restore (skip the account/settings files).
• Platform constraint validated: confirmed the Android 15 owner-only storage behavior and a working write path around it.

What this de-risks: "can it be done + what exactly to move" is answered. Remaining risk is productizing access without a technician (Shizuku / share-sheet UX) and the legal/privacy gates (EULA, COPPA) — not feasibility.

Detailed technical runbook (folder/file framework, include-vs-skip, permission workarounds) lives in our internal notes: self-private/petry-household/our-technology/minecraft-world-backup-and-restore/.