Hex

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 analysis tooling I actually need instead of Hex — and understand the idea worth copying.

**A notebook that becomes an application.** The analysis and the thing a colleague uses are the same document, so the work does not have to be rebuilt to be shared. That is genuinely valuable and it is the part to reproduce; the managed Python environment is what you take on.

STACK
- Marimo or Quarto for the notebook half. **Do not write a notebook engine**
- Node 20+ with Fastify only for scheduling, publishing and access
- SQLite through better-sqlite3 for runs and permissions
- Caddy in front

WHY NOT JUPYTER, HONESTLY
- A traditional notebook stores output alongside code, runs cells in whatever order somebody clicked, and produces a document whose state nobody can reproduce. That is why notebooks have a bad reputation in production
- Marimo stores the notebook as a plain Python file, works out the dependency graph between cells, and re-runs what depends on what changed. That makes it reproducible, diffable and reviewable — and it publishes as an application directly
- Quarto is the other good answer if the output is a document rather than an app
- Either way the notebook is **a file in a repository**, not a blob in a database

THE PUBLISHING HALF, WHICH IS WHAT YOU BUILD
- A published notebook is a URL with inputs at the top and results below, running server-side
- Permissions per notebook, checked on the server: who may view, who may run, who may edit
- Parameters are typed and validated, and a parameter is never interpolated into SQL. **Named parameters, always** — a published analysis that takes a text box is a query box for the whole company
- A run is queued, with a concurrency cap and a timeout. One analyst's cross join must not take the machine down
- Results cached by a hash of the inputs and the notebook version, so ten people opening the same report is one run

THE DATABASE CONNECTION
- Read-only, or a replica. An analysis tool should be incapable of writing
- A statement timeout and a row cap on everything
- Credentials held by the server and never in the notebook. A notebook in a repository with a password in it is a password in the repository forever

SCHEDULING
- A notebook on a cron with a timezone, results stored, and a message with the summary inline rather than a link nobody opens
- Every run recorded with its inputs, its duration and its outcome, so 'why did Tuesday's number differ' is answerable
- Failure alerts to the owner, once, with the error

THE DISCIPLINE THAT MAKES IT WORTH ANYTHING
- **Metric definitions in files, shared with the rest of your reporting**, not redefined in each notebook. Otherwise three analyses give three answers and the meeting is about whose SQL is right
- Notebook in version control, reviewed like code, with the environment pinned so a run in November matches a run in March

WHAT MATTERS MOST
A file-based reproducible notebook and typed parameters. The first is what makes the analysis trustworthy a year later; the second is what stops a published report becoming a hole into your database.