Sanity

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build the content layer I actually need instead of Sanity — and know which half is hard.

**Real-time collaborative editing.** Two editors in the same document, with presence, converging correctly. That is the part you should not write, and the answer is an existing conflict-free replicated data type library rather than a homemade one.

The rest — a schema, an editing screen, an API — is a fortnight, and it fits your content better than a generic one.

STACK
- Node 20+ with Fastify, server-rendered HTML for the editing screens
- SQLite through better-sqlite3, WAL mode, with FTS5
- Yjs if you genuinely need simultaneous editing; a per-document lock if you do not
- Caddy in front

THE DATA MODEL
- types: id, name, fields_json — the schema, defined in files in your repository and versioned with the code that renders it
- documents: real tables per type, created and altered by generated migrations. **Not a generic key-value store** — real columns mean real constraints and queries that stay fast
- revisions: id, document_id, field, old_value, new_value, actor_id, at — append-only
- drafts: a separate row from the published document, so an unfinished edit is never what a reader sees
- assets: id, path, sha256, mime, bytes, width, height, alt, focal_x, focal_y
- references between documents as real foreign keys, so a delete cannot orphan a page

DRAFT AND PUBLISH, WHICH IS THE PART THAT MATTERS
- Every document has a draft and a published version. Editing touches the draft; publishing copies it across, in one transaction, with a revision row
- **A preview URL that renders the draft**, so somebody can see the page before it exists. That is the feature editors actually judge the system by
- Scheduled publishing by a worker that is idempotent
- Unpublishing leaves the document and clears the published version, so nothing is lost by accident

COLLABORATION, HONESTLY
- If two people genuinely edit one document at once: Yjs, with the server as a relay and a periodic persist. Writing your own is a research project and getting it subtly wrong loses somebody's writing
- If they do not: a per-document lock with a visible indicator of who is editing. Worse, never destructive, and it is the right trade for most content teams. **Choose deliberately and write down which**

THE API
- REST per type with filtering, field selection, reference expansion and pagination
- Draft content requires a token; published content is public and cached hard with an ETag
- Webhooks on publish, signed and retried, so the site rebuilds itself
- A statement timeout and a row cap on everything

ASSETS
- Uploads streamed to disk, type from content, stored by hash, EXIF stripped including location
- Transformations on demand with **signed parameters**, or nobody can stop your server being used as a free image farm
- A focal point per image so cropping keeps the subject, which is a stored coordinate rather than a model

WHAT MATTERS MOST
Draft-and-preview, and real columns. The first is what makes editors trust the system; the second is what stops it becoming slow and unconstrainable once there is content in it.