Grist

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 the relational sheet I actually need instead of a hosted Grist: typed columns, real relations, formulas with a proper language, and access rules per row.

Read this first: Grist is open source and self-hosting it is a real answer — the fee buys a hosted instance with backups, sharing and row-level access rules. Build this when you have one dataset that has outgrown a spreadsheet and you want it to be a real schema rather than a grid of guesses.

STACK
- Node 20+ with Fastify, server-rendered HTML with vanilla JS for the grid
- SQLite through better-sqlite3, WAL mode. It is already a relational engine — use it as one
- No client-side framework
- Caddy in front

THE DATA MODEL
- tables: id, name, label, description
- columns: id, table_id, key, label, kind, position, formula, is_formula, config_json, is_required, is_unique
- Data rows live in real SQL tables with real columns and real constraints, created and altered by generated migrations. Not a key-value store — a generic store makes every constraint impossible and every query slow
- references: a column of kind ref is a foreign key to another table's row id; reflist is a join table. Both are real
- row_revisions: id, table_id, row_id, column_key, old_value, new_value, actor, at — append-only
- views: id, table_id, kind, name, filters_json, sorts_json, group_by, visible_columns_json, linked_view_id
- access_rules: id, table_id, column_key, role, permission, condition — the paid feature, and it belongs in the core

COLUMN TYPES AND CONSTRAINTS
- text, integer, decimal with precision, money with a currency, boolean, date, datetime with a zone, choice, choice list, reference, reference list, attachment, any
- Each type has a parser, a validator, a formatter, a comparator, a filter set and a CSV form. Write that contract once
- Constraints from the schema: required, unique, a check expression, and a foreign key that actually prevents an orphan
- Type conversion is a migration with a dry run that reports the rows that would fail — never a silent coercion that turns a date into a number

FORMULAS, WHICH IS THE REASON TO CHOOSE THIS
- A real expression language rather than spreadsheet functions: variables, comparisons, conditionals, arithmetic, string and date operations, and aggregates over a reference list
- Formulas reference other columns by name and referenced rows by dotted path — `client.name`, `sum(orders.total)`
- Parsed into an AST and evaluated on read, with a dependency graph so a cycle is rejected at save time rather than found at render time
- Errors shown in the cell with the reason, and a formula that fails on one row does not break the table
- If you want Python-like power, implement a small safe interpreter over a fixed set of builtins, sandboxed with a time limit — never eval, and never anything that can reach the filesystem or the network

VIEWS AND LINKING
- Grid, card, chart and form
- Linked views: select a row in one and the other filters to its related rows. This is the feature that makes a relational sheet feel different from a spreadsheet, and it is a filter parameter rather than anything clever
- Filters composable, sorts on several columns, grouping with subtotals, hidden columns, frozen first column
- Summary tables: a group-by with aggregates, computed at query time and never stored

ACCESS RULES
- Per table, per column, per row: a role and a condition over the row's own values or the user's attributes
- 'A regional manager reads rows where region equals their own, and cannot see the salary column'
- Enforced in the single query path on the server. A hidden column must be absent from the response, not hidden in the browser
- Default deny, and a page generated from the rules showing what each role can do

THE GRID
- Keyboard first: arrows, Enter to edit, Escape to cancel, Tab to advance, copy and paste a rectangle including from a real spreadsheet
- Virtualised so fifty thousand rows scroll
- Undo and redo backed by the revision log
- Validation errors on the cell

IMPORT, EXPORT AND API
- CSV and Excel import with a mapping step and a dry run that reports what would fail before anything is written
- Export any view as CSV, and the whole document as SQLite — which it already is, and which is the cleanest escape hatch in this category
- REST per table with filtering, pagination and the same access rules; tokens with scopes
- Webhooks on change, signed and retried

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, HASH_SALT
- Migrations on boot, each once; a schema change through the interface writes a migration file
- Nightly backup off the machine, restore script
- Health endpoint

WHAT MATTERS MOST
Real columns and the formula dependency graph. Put the data in proper SQL tables with proper constraints from the first commit — that decision cannot be undone once there is data — and build the cycle detection before anybody writes a formula that refers to itself.

Give me the repository, migrations, .env.example, a seed document of three related tables with formulas and access rules, and a README with deploy steps behind Caddy.