Feathery

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 engine that replaces Feathery: long conditional applications with document upload and verification, writing into the systems behind them.

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 a feature
- Caddy in front

THE DATA MODEL
- forms: id, slug, name, version, definition_json, status, 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 on Tuesday must not change what somebody answered on Monday
- steps: part of the definition — id, title, fields, condition
- fields: id, key, kind, label, help, placeholder, required_when, validation_json, options_json, mask
- submissions: id, form_id, form_version, token, status, started_at, last_seen_at, submitted_at, ip_hash, referrer_host
- answers: id, submission_id, field_key, value_text, value_num, value_json, answered_at — one row per answer, so a partial submission is just fewer rows
- documents: id, submission_id, field_key, path, sha256, mime, bytes, pages, status, verified_at, rejected_reason
- reviews: id, submission_id, reviewer, decision, note, at
- deliveries: id, submission_id, target_id, status, attempts, response_excerpt, at
- events: id, submission_id, kind, field_key, meta_json, at — append-only, and this is where the drop-off analysis comes from

THE FORM DEFINITION
- One JSON document describing steps, fields, conditions and validation. It is data, versioned, and diffable
- Conditions as a small explicit expression tree over earlier answers — never arbitrary code, never a string evaluated at runtime
- The same evaluator runs on the server and in the browser, from one module, so what is shown and what is accepted can never disagree
- Validated on save: a reference to an unknown field, an unreachable step, or a condition that can never be true is an error before publishing rather than a dead end for an applicant

FILLING A LONG FORM
- Every step is a real page with a real POST. Back and forward work. A refresh loses nothing
- Progress saved on every step, resumable by a long random token sent to the applicant's email — a forty-field application filled on a phone will be finished on a laptop three days later, and losing it is losing the applicant
- A progress indicator that is honest about the remaining steps, given the conditions already met
- Errors shown on the field, in text, with the entered value kept
- Works with JavaScript disabled, end to end. Enhancement adds masking, live validation and conditional show-and-hide within a step

DOCUMENT UPLOAD AND VERIFICATION
- Upload streamed to disk, type from content rather than filename, size capped, and a per-submission quota
- Images and PDFs accepted; a photo from a phone is resized and rotated by its EXIF orientation before storage, and the orientation tag stripped
- A preview shown back to the applicant so a photo of a thumb is caught by the person who took it
- Optional text extraction to check the document is what it claims — a date, a name, a number — with a confidence, presented to a reviewer rather than deciding on its own
- Documents are personal data of the most sensitive kind. Encrypted at rest, served only through a permission check, with an explicit retention period and a sweeper that actually deletes

REVIEW AND DELIVERY
- A queue for submissions needing a human: approve, reject with a reason, or return to the applicant asking for one field again
- Returning a submission reopens exactly the steps needed, not the whole form
- Delivery targets: an HTTP endpoint with a signature, an email, a row written into a database, a file dropped somewhere. Each retried with backoff, each recorded, each idempotent so a retry does not create a duplicate record downstream
- A dead-letter list with a one-button replay

MEASURING, WHICH IS HOW A LONG FORM GETS SHORTER
- Drop-off per step and per field, computed from the events table
- Time spent per step, and the fields that get corrected most
- Completion rate by device — a long form on a phone is a different form
- Every number computed at query time from events

ACCESSIBILITY, WHICH IS NOT OPTIONAL HERE
- Labels tied to inputs, errors announced, fieldsets for groups, a visible focus ring, and a logical tab order
- These forms are often how somebody applies for something they need. An inaccessible one excludes exactly the people least able to work around it

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, HASH_SALT, ENCRYPTION_KEY, SMTP_URL
- Migrations on boot, each once
- Nightly backup off the machine, restore script, and a documented retention policy per form
- Health endpoint

WHAT MATTERS MOST
Resumability and one condition evaluator. Build the token-resume path and the shared evaluator first, then fill a twenty-field form on a phone, close the browser, and finish it a day later on a laptop. Everything else here is field types.

Give me the repository, migrations, .env.example, a seed form of six conditional steps with an upload, and a README with deploy steps behind Caddy and the retention policy stated.