What we built
A form builder that can hold a real process
Rules, shared lists, versioned forms, and one record that follows a subject across many updates.
In depth
The four capabilities worth choosing it for
Each of these has a documentation section of its own. These are the summaries.
Rules and logic
Questions that compute, require and validate each other
Conditional logic shows and hides questions. Rules go further: they derive values, make a field required only in the situations where it matters, and enforce constraints that span several answers at once. You can reword a question later without breaking any rule that depends on it.
Read the docs →- Calculated fields
- A question whose value is derived — an age from a date of birth, a total from line items. The respondent sees it fill in as they answer, read-only rather than as an empty box.
- Conditional requiredness
- "Required only when the answer to something else was X", without turning one question into three near-duplicates.
- Cross-question validation
- An end date before its start date, a total that must match its parts. The message appears against the field it concerns.
- Re-run on the server
- The browser evaluates rules for immediate feedback; the API evaluates the identical compiled plan again and its result is what gets stored. Client-supplied values for calculated fields are discarded.
Dropdown lists
Reference data managed once, used everywhere
A list of 784 districts does not belong pasted into a dropdown on four different forms. Dropdown lists hold that data centrally, upload from CSV, and bind to any choice question — so correcting a spelling fixes it everywhere at once.
Read the docs →- Cascading dropdowns
- District narrows Block, Block narrows Site. Each level offers only the options belonging to the answer above it.
- Lookups and auto-fill
- Attach metadata to a list item and pull it into other fields when that item is chosen — a code, a region, a contact.
- Searchable at any size
- Large lists become type-to-search automatically rather than a select someone has to scroll for a minute.
- Organization or platform scope
- Keep a list to one workspace, or publish a shared dictionary that every workspace can draw on.
Publishing
Published versions are immutable, and responses remember theirs
Publishing freezes a version of the form. Editing afterwards changes the draft, not what respondents are currently filling in, until you publish again. Every response records the version it was submitted against, so an answer is always readable against the questions that were actually asked.
Read the docs →- Draft and live are separate
- The builder shows unpublished changes explicitly, so nobody discovers a half-finished edit went live an hour ago.
- Responses bind to a version
- Reworded a question last month? Older responses still display against the wording their respondent saw.
- Access controls on the link
- Password protection, sign-in requirement, an expiry date, a response cap that closes the form on its own, and one-response-per-person.
Data apps
Many forms about the same subject, over time
A monitoring round is not one form. It is a respondent block, then a section repeated per site covered, then a summary — and next quarter the same subject is monitored again. A data app is one link that walks a field worker through that whole sequence and files the result under the subject it concerns.
Read the docs →- Record types
- Define the subject an app collects data about — a site, a household, a patient — and what identifies it.
- Ordered, repeatable, conditional steps
- Each step is a form, filled once or any number of times, with minimums and maximums, and skipped entirely when it does not apply.
- Records and timeline
- Everything ever collected about one subject, in one place, in the order it happened.
The builder
Everything else in the box
The parts you would expect, listed rather than implied.
Responses
What happens after someone presses submit
Administration
Built for more than one person
Workspaces, roles and an audit trail, because most data collection is something a team does together and someone is accountable for.
Security
What we do, stated plainly
These are engineering measures that are implemented, not certifications. See security and compliance for what we do and do not hold.
Two-factor authentication
TOTP from any authenticator app, with single-use recovery codes. Secrets are encrypted at rest, and turning it off requires the account password.
Server-side answer validation
Every submission is re-validated against the published version: required fields, types, option membership, bounds, and payload size. The browser’s word is never taken for it.
Guarded outbound webhooks
HTTPS only, with addresses resolved and checked at delivery time so a webhook cannot be pointed at an internal or cloud-metadata address.
- Sessions
- One day, fixed at sign-in. Nothing extends it in the background; when it ends you are signed out.
- Rate limiting
- Shared across servers, with stricter limits on sign-in, two-factor and password reset.
- File uploads
- Type and extension allowlisted, size enforced at the storage layer, and checked against the actual stored object.
- Your organization's data stays separate
- Every request is scoped to one organization and checked server-side, including files and dropdown lists.
- Secrets at rest
- Webhook secrets and two-factor seeds are encrypted; the API never returns them once set.
- Response data
- Yours. Exportable at any time, and deletable — including individual responses.
Reference
Every field type
What each one stores and when to reach for it is covered in the field types documentation.
- Short text
- Long text
- Number
- Phone
- URL
- Single choice
- Multiple choice
- Dropdown
- Star rating
- NPS (0–10 score)
- Slider
- Date
- File upload
- Signature
- Matrix
- Section header
- Repeating section
Build your first form
Create a workspace, build a form, and share a link. Nothing to install, and no card needed to start.