Technical read
For the System Design Bros
Extension points, electron-vite, and local-first storage
The desktop shell behind CreatorBox โ thin core, plugin extension points, Electron + Vite, and why drafts stay on disk.
Extension-point model
The core binary stays thin. Features โ export presets, platform adapters, asset pipelines, niche tool packs โ register through extension points instead of forking the main app. New creator workflows ship as plugins, not rewrites of the shell.
Electron + Vite (electron-vite)
Renderer gets Vite HMR for fast UI iteration; main and preload bundles stay explicit. Native APIs (filesystem, dialogs, codecs) live behind preload IPC so the React surface does not inherit Node foot-guns.
Local-first storage
Drafts, renders, and reference boards live on disk โ SQLite and project folders โ not a sync server in v1. Creators work with large assets, need offline, and care about egress; local storage avoids upload tax on 4K timelines and keeps iteration snappy.
Why these choices
Extension points decouple release cadence from every niche workflow. Electron-vite optimizes where the product spends time (UI-heavy editor). Local-first defers backend complexity until retention proves cloud value โ privacy and performance win by default.