Coda

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 a document with databases in it, replacing Coda — and know why this is ALMOST.

Tables and pages are separately easy. What is hard is **one formula language that spans the whole document**: a paragraph that references a table's rows, a button that mutates data from inside the text, a table that filters by a value defined three pages away. That single namespace is the product, and it is a compiler problem rather than a feature.

STACK
- Node 20+ with Fastify, server-rendered HTML with a little vanilla JS
- SQLite through better-sqlite3, WAL mode
- Caddy in front

THE DATA MODEL
- docs: id, name, owner_id, created_at
- pages: id, doc_id, parent_id, title, content_json, position — the content is a block tree of text, headings, and embedded views
- tables: id, doc_id, name; columns: id, table_id, key, label, kind, formula, config_json
- Rows in real SQL tables per user table, created and altered by generated migrations. A generic key-value store makes every constraint impossible and every formula slow
- views: id, doc_id, table_id, kind, filters_json, sorts_json, group_by, columns_json — embedded into a page, so a view is a block
- controls: id, doc_id, kind, name, value_json — a select, a date, a slider defined on a page, referenced by formulas anywhere in the document
- buttons: id, doc_id, label, action_json, condition — insert a row, modify rows, run a sequence
- formula_deps: from_kind, from_id, to_kind, to_id — the dependency graph, which is what makes recomputation correct

THE FORMULA LANGUAGE, WHICH IS THE PROJECT
- One expression language, one namespace: tables, columns, rows, controls and named values are all addressable from anywhere in the document
- Parsed into an AST, type-checked, and compiled into a dependency graph. A cycle is rejected at save time, not discovered at render
- Values: numbers, text, dates with zones, booleans, and lists of rows — the last one matters, because filtering and aggregating a table is the most common thing anybody writes
- Functions in three groups: arithmetic and text, dates, and list operations — filter, map, sum, count, first, sort, group. That is most of a spreadsheet's usefulness in about thirty functions
- Row references are stable identifiers, not positions. Sorting a table must not change what a formula points at
- Errors shown in place with the reason, and a formula that fails on one row does not break the page

RECOMPUTATION
- On a write, walk the dependency graph and recompute only what depends on what changed. Recomputing everything is what makes these documents slow at the size where they become useful
- Formulas evaluated on read where the input is a query, and cached with an invalidation keyed to the graph
- A formula that touches a whole table must have a row cap and a timeout, so one careless expression cannot stall a document

BUTTONS AND AUTOMATIONS
- A button is a named action with a condition: add a row, set values on the rows a formula selects, send an email, call an endpoint
- Every press recorded with what it changed. A button that silently modified forty rows and cannot be explained is the worst thing this product can do
- Automations on a schedule or a row change, with the same action vocabulary, every run recorded, retries with backoff, and a per-recipient daily mail cap

PACKS, HONESTLY
- Two-way integrations with other services are what the paid tier is really selling. Each one is an adapter with authentication, pagination and rate limits, and each breaks when the other service changes
- Build the two you need as small modules with fixtures and tests. Do not build a plugin framework for integrations you have not written

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, ENCRYPTION_KEY
- Migrations on boot, each once; nightly backup off the machine, restore script
- Health endpoint that evaluates a fixture formula

WHAT MATTERS MOST
The dependency graph. Build the parser, the graph and the incremental recomputation before a single page looks good — everything else in this product is a table or a text editor, and both of those are solved.