Tally

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-style form builder that replaces Tally: I type a page, and typing a question makes a field.

Read this first: Tally's free tier is unusually generous — unlimited forms and responses — so the money case for building this is weak. The reasons that hold up are: the responses never leave your machine, the form lives on your own domain with no third-party script, and you can put it wherever your product needs it.

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

THE IDEA
- The form is a document. You write a page and a marker turns part of it into a field, in the middle of a sentence if that is where it belongs
- So the editor is a writing surface, not a stack of blocks to configure, and the rendered form keeps the prose around the fields
- Everything below serves that. Any feature that turns the page back into a list of labelled boxes should be left out

THE DATA MODEL
- forms: id, slug, name, version, content_json, theme_json, status, published_at, close_at, response_limit
- form_versions: id, form_id, version, content_json, published_at — a submission records the version it was filled against, because a form edited today must not change what somebody answered yesterday
- submissions: id, form_id, form_version, token, status, started_at, submitted_at, ip_hash, referrer_host, country, payment_id
- answers: id, submission_id, field_key, value_text, value_num, value_json
- files: id, submission_id, field_key, original_name, path, sha256, mime_detected, bytes, scan_status
- notifications: id, form_id, kind, target, template_md, condition_json
- events: id, submission_id, kind, field_key, at — append-only, and where drop-off analysis comes from
- The content is one document tree of text nodes and field nodes. That representation is the design; everything else derives from it

WRITING THE FORM
- A rich text editor. Headings, paragraphs, lists, images, dividers, page breaks — it is a page
- Typing a marker inserts a field inline, configured in a panel beside it
- A live preview at phone and desktop width showing the real thing
- Themes: font, colours, spacing, cover image. It should look like part of the site it belongs to

FIELD KINDS
- Text, long text, number, email, phone, url, date, time, dropdown, multiple choice, checkboxes, ranking, rating, scale, matrix, file upload, signature, payment, hidden
- Hidden fields filled from query parameters, which is how a form knows who sent somebody to it
- Each kind has a parser, a validator, an inline rendering that fits inside a sentence, and a CSV form

LOGIC
- Conditional show and hide, and jumps to another page
- An explicit expression tree over earlier answers, never evaluated code, with one evaluator shared by the server and the browser so what is shown and what is accepted cannot disagree
- Calculations with a dependency graph, so a cycle is rejected at save time rather than found by somebody filling the form
- Validated on publish: an unknown reference, an unreachable page or a condition that can never be true is an error before anybody sees it

FILLING IT IN
- Each page is a real POST. Back and forward work, a refresh loses nothing
- Progress saved per page, resumable by a token
- Errors on the field with the value kept
- Works with JavaScript disabled apart from live calculations, which are enhancement
- Fully accessible: labels tied to inputs, errors announced, a logical tab order, a visible focus ring. A form is often how somebody asks for something they need

UPLOADS
- Streamed to disk with a hard limit enforced as bytes arrive, type from content rather than filename, an allow-list per field
- Stored by hash outside the web root, EXIF stripped from images, scanned if a scanner is available
- Served only through signed expiring links, never attached to a notification email

PAYMENTS
- Hosted checkout; no card data reaches this application
- The amount computed on the server from the answers, never taken from the browser. This is the classic way a payment form is abused
- Marked paid only from a verified webhook, with idempotency by event id

AFTER
- Notifications to the owner, conditionally, and an autoresponder with a copy of the answers, both with a per-recipient daily cap so a loop cannot mail somebody four hundred times
- A thank-you page that can be written like any other page, with the answers available in it, or a redirect
- Export CSV and JSON, complete, including partials

RESULTS
- A table of submissions, searchable and filterable, plus a summary per question
- Drop-off per page and per field, which is how a long form gets shorter
- Everything computed at query time

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, HASH_SALT, SMTP_URL, PROVIDER_KEY, PROVIDER_WEBHOOK_SECRET
- Migrations on boot, each once
- Nightly backup off the machine, restore script
- Health endpoint

WHAT MATTERS MOST
The inline field and one evaluator. Build the document tree with fields inside sentences, then fill a twenty-field form on a phone, close it, and finish it a day later. Everything else here is field types.

Give me the repository, migrations, .env.example, a seed form with logic and a payment, and a README with deploy steps behind Caddy.