Jotform

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 builder that replaces Jotform: long forms with logic, payments and uploads, live today, maintained by somebody who does not write code.

STACK
- Node 20+ with Fastify, server-rendered HTML with a little vanilla JS
- SQLite through better-sqlite3, WAL mode
- No client-side framework — a multi-step form is server-rendered pages, and that is what makes it reliable
- Caddy in front

THE DATA MODEL
- forms: id, slug, name, version, definition_json, status, theme_json, published_at
- form_versions: id, form_id, version, definition_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, quarantined
- payments: id, submission_id, provider_ref, amount_cents, currency, status, paid_at
- notifications: id, form_id, kind, target, template_md, condition_json
- deliveries and events, both append-only

THE DEFINITION
- One JSON document: pages, fields, conditions, validation, notifications. Data, versioned and diffable
- Conditions as an explicit expression tree over earlier answers. Never evaluated code
- One evaluator module, used by the server and by the browser, so what is shown and what is accepted can never disagree
- Validated on save: an unknown field reference, an unreachable page, or a condition that can never be true is an error before publishing rather than a dead end for somebody filling it in

FIELD TYPES
- Text, long text, number, email, phone, date, time, dropdown, radio, checkbox, matrix, rating, scale, address, name, file upload, signature, hidden, and a page break
- Signature captured as a path and rasterised at print resolution, not screenshotted from the canvas
- Address with sensible international handling — never a form that requires a state and a five-digit postcode
- Each type has a parser, a validator, a formatter, a CSV form and an accessible markup template. Write that contract once

BUILDING WITHOUT CODE
- A builder where fields are added, reordered and configured, with a live preview at phone and desktop width
- Templates to start from, which is most of why the original is bought — build a dozen good ones rather than three hundred mediocre
- Every change is a draft until published, and publishing writes a version
- The person maintaining this is not a developer. Every error message in the builder is a sentence, not a stack trace

FILLING IT IN
- Every page is a real POST. Back and forward work, a refresh loses nothing
- Progress saved per page and resumable by a token emailed to the filler — a long form on a phone gets finished on a laptop three days later
- An honest progress indicator given the conditions already met
- Errors on the field with the value kept
- Works with JavaScript disabled, end to end

UPLOADS
- Streamed to disk with a hard byte limit enforced as it arrives, type from content rather than filename, an allow-list per field
- Stored by hash outside the web root; the original name kept as a label only, with directory components stripped
- EXIF stripped from images, including the location
- Scanned with ClamAV if available, quarantined until the scan finishes
- Served only through signed expiring links, never attached to a notification email

PAYMENTS
- Hosted checkout from one provider; no card data ever 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
- Webhook with signature verification and idempotency by event id; the submission is marked paid only from the webhook
- A submission with a failed payment is kept, not discarded

NOTIFICATIONS
- To the owner on submission, conditionally, with the answers laid out readably
- An autoresponder to the person who filled it in, with a copy of their answers
- Each with its own condition, each recorded, and a per-recipient daily cap so a loop cannot mail somebody four hundred times

SENSITIVE DATA, HONESTLY
- If a form collects health or payment data, the compliance regimes the original advertises are paperwork and audits, not code. You can build the technical controls — encryption at rest, access logs, retention, minimisation — but you cannot self-certify. Say so in the README and take proper advice before collecting that kind of data
- Retention per form, enforced by a sweeper that actually deletes, with the policy shown to the person filling the form

RESULTS
- A table of submissions with the answers, searchable and filterable
- Export CSV and JSON, complete, including partials and file links
- Drop-off per page and per field, which is how a long form gets shorter

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

WHAT MATTERS MOST
Resumability, one evaluator, and computing the payment amount on the server. Build those three first, 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, an upload and a payment, and a README with deploy steps behind Caddy and the compliance caveat stated plainly.