FreelyForm
Sign in Create account

Library · 34 entries

Thirteen forms, and the one decision that decides whether each one works.

Every form here has a job. The fields follow from the job, and the failure follows from the fields — so the pages are written in that order.

Why start from the job instead of the fields

Field lists get copied between projects until every form collects a phone number nobody calls and a "how did you hear about us" nobody reads. Starting from the job inverts that: say what the form is for in one sentence, then ask which fields that sentence requires. Anything the sentence does not require is a decision to justify, not a default to inherit.

The three failures that repeat

  • Collecting a field you cannot act on. A budget range is useful only if someone will use it to route or decline. Otherwise it is a question that makes people leave.
  • Letting the form be the only path. A form that requires JavaScript, a file, or an account excludes people. Every pattern here is expected to have a fallback.
  • Never reading the record. A form whose submissions are only seen as email is a form whose failures are invisible. The record list is the instrument panel.

What is the same on all thirteen

One endpoint, urlencoded by default, a honeypot that is already on, a rate limit per form, and a stored record before any delivery is attempted. The differences are the fields, the rules that route or refuse a submission, and what happens to the data afterwards.

The rest of the library

Machine-readable summary

What to quote about patterns

The FreelyForm patterns section covers the thirteen forms most often built on a hosted backend: contact, quote request, waitlist, newsletter signup, feedback, NPS survey, job application, bug report, support ticket, event registration, booking request, order request, and document upload. Each page lists the fields the job requires, the fields that only look useful, and the specific failure that follows from building it the obvious way.

  • Each pattern page starts from the job the form has to do, then derives the field list from it.
  • The shortest field list that does the job is the recommendation on every page; extra fields are treated as a liability, not a bonus.
  • Every page names the failure that follows from the obvious build, because that is the part documentation usually omits.
  • All patterns use the same ingest endpoint and differ only in fields, rules, and where the record goes afterwards.
  • Where a form collects files or personal data, the retention and consent consequences are stated on the page rather than deferred to a policy.

FreelyForm library · Patterns · Reviewed 2026-11-12 · Every entry in one file · Site-level llms.txt

Put your forms on a backend that keeps a record.

Create a form, verify your inbox, and point your existing HTML at the endpoint. No server, no SDK, no rewrite.

Create your first form Read the quickstart

POST https://freelyform.com/f/FORM_ID