Prompt Organizer
Open app

Local-first · Defined technically · v3.0

A workbench that runs in your tab.

"Local-first" is overloaded as a marketing word. Here's what it means for Prompt Organizer, mechanically: a static app shell, a core prompt library written to IndexedDB in your browser, explicit optional network actions, and a portable JSON vault you can read in any text editor.

Inspect browser storage and the network tab. Both parts of the architecture are observable.

Open the workbench Read the architecture Or try the starter pack
  • Browser-local core
  • Explicit network actions
  • Portable JSON vault

What connects

The hosting provider serves the page and receives ordinary HTTPS request metadata. Prompt bodies in the core library are not included in those page requests.

  • Core library.Saving, editing, tagging, local search, import, and export operate against browser storage.
  • Optional first-party flow.Prompt Library connects when you browse, import, submit, or manage hosted items.
  • Optional third-party flow.Prompt Lab, checkout, analytics when enabled, and destinations you open connect only when their disclosed trigger occurs.

Local-first, defined technically

Four claims. Each one verifiable.

"Local-first" gets used to mean a dozen different things - sometimes "we sync, but optimistically", sometimes "your data goes to our cloud but encrypted". Here it means something narrower and more checkable.

Network behavior by action core versus optional 
// Hosted page
HTML, CSS, JavaScript, media
and ordinary HTTPS metadata

// Browser-local core
save · edit · tag · local search
import · export · vault writes

// Optional, user-triggered
Prompt Library · BYOK providers
checkout · configured analytics
destinations you choose to open
  1. 1. Static app shell.Vercel serves HTML, CSS, JavaScript, media, and fonts. That request boundary is separate from the prompt library stored in your browser.
  2. 2. Browser-local core.Prompts, tags, references, and SKILL packages are written to IndexedDB on your device by default.
  3. 3. Explicit network actions.Prompt Library, BYOK model calls, checkout, configured analytics, and destinations you open are named in the product before or where they occur.
  4. 4. Portable JSON vault.The vault is plain, human-readable JSON. You choose where it lives and when it is copied, synced, or shared.

Run the proofs yourself. They take a minute.

Open dev tools. Network tab. Reload the app, note the hosting requests, then save a prompt. Core edits do not initiate prompt-content requests. Optional flows appear when you deliberately use them.
Inspect IndexedDB. Application tab, IndexedDB, promptOrganizer. There's your library, in a database file on your disk, indexed by id. You can see every prompt body, every tag, every reference.
Trigger one optional flow. Open Prompt Library or run a BYOK provider call and watch the disclosed destination appear. The distinction is observable instead of inferred from a mock counter.

Where your prompts actually go

1 You type a prompt browser · this tab
2 IndexedDB on your disk ~/Library/Caches/...
3 Optional destination only when you choose it

Core library writes stop at browser storage. Prompt Library, BYOK provider, checkout, analytics, and external-destination requests follow the separate, disclosed path only when triggered.

Privacy, durability, portability - by architecture, not by promise.

Privacy. The prompts you refine reflect your judgment, your clients, and your evaluation criteria. The core library remains in browser storage unless you deliberately submit, send, export, or otherwise move content through a named flow.

Durability. The library survives us when you keep a vault or export. Open the JSON in a text editor, diff it in Git, or hand it to another tool that understands the documented format.

Portability. The vault is yours in the strong sense: it lives on your filesystem, in a format you can read, with no proprietary container or DRM. Move it to a different machine. Sync it through iCloud. Email it to your future self.

prompt-library.vault.json Illustrative schema 
// Plain JSON · schemaVersion 3 · FNV-1a checksum
{
  "schemaVersion": 3,
  "checksum": "<verified checksum>",
  "prompts": [
    {
      "id": "pr_8f3a",
      "title": "Weekly status update",
      "body": "Summarize {{ project }}...",
      "tags": ["writing", "status"]
    }
  ],
  "history": []
}

Plain JSON · readable in a text editor · stored where you choose

Where else would you keep these?

An honest look at the three options most people land on by default, and the structural tradeoffs each one is quietly making.

On small screens, each row stacks so every tradeoff is readable without sideways scrolling.

Local-first workbench static · no account Cloud-hosted notes Notion / Google Docs Vendor prompt UI ChatGPT / Claude history
StorageIndexedDB on your machineVendor's databaseVendor's database
Prompt-data pathBrowser-local core; explicit provider callsVendor-hosted storageVendor-hosted conversation
Durability if vendor disappearsIt's a file on your diskLocked behind loginLost
Portability across toolsJSON and configurable send-to destinationsCopy-pasteTrapped in one vendor

Your craft deserves a place that respects it.

A local-first workbench isn't a smaller cloud app. It's a different shape of software - one that runs in your tab, writes to your disk, and exits when you close it. The library you build today is still yours in five years, whether we're here or not.

Open the private workbench See the network disclosure