Paperform

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 form that reads like a page, replacing Paperform: I write a document, the questions are part of the prose, and the total adds itself up.

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 ONE IDEA
- The form is a document. You write a page of prose and a question is inserted inline, in the middle of a sentence if that is where it belongs
- 'We will deliver to [address] on [date] for [quantity] people' is one sentence with three fields in it, and it reads better than four labelled boxes
- So the editor is a writing surface, not a block assembler, and the rendered form keeps the prose around the fields
- Everything below serves that. If a feature would turn the page back into a stack of labelled boxes, leave it out

THE DATA MODEL
- forms: id, slug, name, version, content_json, theme_json, status, published_at
- form_versions: id, form_id, version, content_json, published_at — a submission records the version it was filled against
- fields: within the content — key, kind, label, help, required, validation_json, options_json, calculation, price_json
- submissions: id, form_id, form_version, token, status, started_at, submitted_at, total_cents, currency, payment_id, ip_hash
- answers: id, submission_id, field_key, value_text, value_num, value_json
- coupons: id, code, kind, value, max_uses, used_count, expires_at, applies_to_json
- payments: id, submission_id, provider_ref, amount_cents, currency, status, paid_at
- The content is one document tree with text nodes and field nodes. That representation is the whole design and everything else derives from it

WRITING THE FORM
- A rich text editor where typing a marker inserts a field inline, configured in a panel beside it
- Headings, paragraphs, lists, images, dividers and page breaks, because it is a document
- A live preview at phone and desktop width, showing the real thing
- Themes: font, colours, background, spacing. It should look like a page from the site it belongs to, not like a form vendor's product

FIELD KINDS
- Text, long text, number, email, phone, date, time, dropdown, radio, checkbox, scale, rating, address, file upload, signature, hidden
- Price fields: a fixed amount, a quantity multiplied by a unit price, an option list with prices, or a value computed from other answers
- Each kind has a parser, a validator, an inline rendering that fits inside a sentence, and a CSV form

CALCULATIONS, WHICH IS WHY THIS PRODUCT IS CHOSEN
- A small expression language over field keys: arithmetic, conditionals, rounding, min and max, and sums over repeated groups
- Parsed into an AST with a dependency graph, so a cycle is rejected at save time rather than found by somebody filling the form
- The running total updates as they type, visible, itemised — a total that appears only at the end loses people
- Tax computed as a rule with its rate and whether prices include it, stated on the page
- Coupons applied against the itemised total with the rule visible
- The server recomputes every calculation from the answers before charging. The browser's total is a display and is never trusted. This is the classic way a payment form is abused, and it is one function to get right

CONDITIONS
- Show or hide a field, a paragraph or a whole page depending on earlier answers
- An explicit expression tree, never evaluated code, with one evaluator shared by the server and the browser so what is shown and what is accepted cannot disagree
- Validated on save: an unknown reference or an unreachable page is an error before publishing

FILLING IT IN
- Page breaks make it multi-step; each page is a real POST, so back and forward work and a refresh loses nothing
- Progress saved and resumable by a token emailed to the person filling it
- Errors on the field with the value kept
- Works with JavaScript disabled apart from the live total, which is enhancement

PAYMENT
- Hosted checkout; no card data reaches this application
- The amount comes from the server's own recomputation, always
- Webhook with signature verification and idempotency by event id; the submission is marked paid only from the webhook
- A failed payment keeps the submission rather than discarding it

AFTER
- Notifications to the owner and an autoresponder with a copy of the answers and the itemised total
- A success page that can be written like any other page, with the answers available in it
- Export CSV and JSON, complete, with totals and payment references

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

WHAT MATTERS MOST
The inline field rendering and server-side recomputation of the total. Build the document tree with fields inside sentences first — that is the product — and never charge an amount that came from a browser.

Give me the repository, migrations, .env.example, a seed order form with prices, a coupon and a calculation, and a README with deploy steps behind Caddy.