Notion

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 me documents with databases in them, replacing Notion — and know what the verdict means.

Two things carry it. **The block editor is years of interaction work**, and it is the reason people tolerate everything else about the product. And **the documents already inside it** are the real lock: exporting is possible, but the shape of what comes out is rarely the shape you had. Build this when your use is narrower than the product — usually a wiki, or a wiki plus one tracker — and build the editor on an existing engine.

STACK
- TipTap or ProseMirror as the editing engine. Do not write a block editor
- Node 20+ with Fastify, server-rendered HTML around it
- SQLite through better-sqlite3, WAL mode, with FTS5
- Caddy in front

THE DATA MODEL
- pages: id, parent_id, title, icon, cover_path, kind, position, created_by, updated_at, archived_at
- blocks: id, page_id, parent_id, position, kind, content_json — paragraph, heading, list item, quote, code, image, table, divider, callout, toggle, page link, and a database view
- Ordering by fractional positions, not floats, or blocks will start swapping places after enough drags
- databases: id, page_id, name; columns: id, database_id, key, label, kind, config_json
- Rows in real SQL tables per database, created and altered by generated migrations. A generic key-value store makes every constraint impossible and every filter slow
- views: id, database_id, kind, filters_json, sorts_json, group_by, visible_columns_json — embedded into a page as a block, which is the idea worth copying
- versions, comments, mentions, links, shares
- Relations as real foreign keys; rollups computed at query time and never stored

THE ONE IDEA WORTH COPYING
- A page is a document until you put a table in it, and the table's views can appear on any other page. That composition — a database rendered as a block inside prose — is the whole product
- Everything else is a document editor and a table editor, both of which are solved problems

THE EDITOR
- Slash commands, Markdown shortcuts while typing, drag to reorder and nest, turn one block into another
- Paste from a web page or a document keeps structure and drops styling
- Autosave with no save button, versions kept, restore available
- A page link that creates the page if it does not exist, with backlinks resolved at save

COLLABORATION, HONESTLY
- Real-time editing needs a conflict-free replicated data type library — use an existing one, because writing one is a research project and getting it subtly wrong loses people's writing
- If that is more than you want, the honest fallback is a per-page lock with a clear indicator of who is editing. Worse, never destructive. Choose deliberately and write down which
- Presence with cursors only if you have real-time; otherwise it is a lie

PERMISSIONS
- Per page, inherited from the parent, with explicit rules overriding. Deny beats allow at every level
- Effective permissions resolved and cached, invalidated when any rule in the chain changes
- Checked inside every query including search, because filtering results afterwards is how a private title leaks into an autocomplete

SEARCH AND ESCAPE
- FTS5 over titles, block text and database cell values, permission-aware in the query
- Export the whole workspace as Markdown with the database contents as CSV, structure intact, in one command. Say so publicly — being able to leave is what makes it safe to arrive
- Import from the common exporters, because that is how anybody arrives here

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, OIDC_*
- Migrations on boot, each once; nightly backup off the machine, restore script
- Health endpoint

WHAT MATTERS MOST
The database-as-a-block, and using an existing editor engine. Those two decisions are the difference between a fortnight and a year, and the second one is not negotiable.