How to Build a Form Builder

Build your own form builder: form definitions, rendering and validating fields, saving submissions, file uploads, notifications, embeds and spam protection.

Mythex Team · 2026-09-29 · 5 min read

A form builder lets people design their own forms — pick fields, set rules, publish a link — and then collects the submissions. Under the hood it is three things: a form definition stored as data, a renderer that turns the definition into a working form, and a submissions store with notifications and export. Before building one, check you really need it: if you just need a contact form or an application form, build that form directly and skip the builder entirely.

Do you need a builder at all?

Your situation	Build this
One or two forms that rarely change	The forms themselves. See how to add a contact form.
Many forms, created by non-developers on your team	An internal form builder
Forms are part of your product (customers create them)	A form builder with accounts, limits and embedding
You mainly want survey results and charts	A survey app

A builder is a bigger project than a form, because every field type has to work in the editor, the public form, validation, storage, notifications and export.

What a form builder needs

Form definitions

Store each form as a list of fields, saved as structured data (JSON in a Postgres column works well). A field might look like:

id — a stable ID that never changes, even if the label does
type — text, email, number, long text, select, checkbox, date, file
label and help text
required, min / max, allowed file types
options for select fields
order, and optionally a condition ("show only if field X is Y")

The editor edits this list; the public form reads it. That's the whole trick: no new code per form.

Submissions

Submissions — form, form version, submitted time, answers keyed by field ID, status (new, read, archived).
Files — uploaded files belong in file storage, with the submission holding a reference, never inside the database row.

Decisions and trade-offs

Versioning. Someone will rename "Phone" to "Mobile number" after 200 submissions. If answers are stored by field ID and each submission records the form version, old submissions still display correctly. Without that, your data quietly scrambles.

Validation runs twice. Check fields in the browser for fast feedback, and again on the server, because anyone can send data directly to your endpoint. The server check is the one that counts.

File uploads. They bring storage costs, size limits, file-type checks and privacy questions (CVs, IDs, medical forms). Limit types and sizes, and make uploaded files private by default, readable only by form owners. See how to add file uploads to your app.

Notifications. "Email me when someone submits" is expected. It needs an email provider and an API key; see how to send emails from your app.

Spam. A public form will be found by bots. Use a honeypot field (hidden from people, filled in by bots), rate limits per IP, server-side validation and, if needed, a CAPTCHA service.

Embedding. An iframe embed is the simplest and safest way to put a form on someone else's website. A script embed looks more native but is harder to build and to secure.

Conditional logic. "Show this field only if…" is popular and multiplies testing. Add it after the basics are solid.

A first prompt that works

Build a form builder web app for my team. Logged-in users create forms in an editor with a live preview. Field types: short text, long text, email, number, date, single select, checkboxes and file upload. Each field has a stable ID, label, help text, required flag and type-specific rules (min/max, options, allowed file types and a 10 MB size limit). Store the form definition as JSON with a version number that increases on each publish. Each form gets a public link and an iframe embed code. Validate submissions on the server against the published version, store answers keyed by field ID with the form version, and put uploaded files in private file storage. Add a hidden honeypot field and a per-IP rate limit. Form owners see a submissions table with status (new, read, archived), a detail view, and CSV export. Store everything in a database. Leave conditional logic and email notifications for later.

Build steps

Editor and definition. Build a form with every field type and look at the saved JSON with the agent. Is it clean and stable?
Public form. Fill it in on a phone. Check validation messages and the confirmation screen.
Server validation. Ask the agent to send a submission that breaks the rules straight to the server, skipping the page. It should be rejected.
Versioning. Rename and reorder fields after a few submissions. Old submissions should still show the right answers.
Uploads. Try a file that's too large and one of the wrong type. Confirm a stranger can't open an uploaded file by guessing its link.
Submissions table and export. Check CSV export with commas, line breaks and accented characters in answers.
Notifications, embeds, logic. Add them one at a time.

Common mistakes

Storing answers by label. Labels change. Use stable field IDs.
Browser-only validation. It's a convenience, not protection.
Public uploaded files. Forms often collect documents people wouldn't want exposed.
No spam protection. A public form can fill with junk within days.
Building a builder for one form. Build the form.
Unlimited submissions on a public product. If customers create forms, set limits per plan, or one popular form can run up your hosting bill.

When a ready-made product is the better choice

Hosted form tools are excellent and cheap for most needs. They've already solved embedding, spam, payments, integrations and accessibility across dozens of field types. If your team just needs forms, use one — see Typeform alternatives and Google Forms alternatives.

Build your own when submissions need to live next to your own data (feeding a CRM or client portal you run), when you need workflows after submission that the tools can't do, when data location or ownership is a requirement, or when forms are a feature of a product you're selling.

Building it with Mythex

On Mythex you describe the builder in chat and test the editor and public form side by side in the live preview. Mythex adds a dedicated database for form definitions and submissions, and enables file storage automatically when your app needs uploads (capped at 1 GB on the Free plan). Notification emails go through a provider you connect with your own key. Publish the app to a mythex.ai link, or your own domain on Pro, and the public form links work from there.

Questions

How does a form builder store forms?

Usually as a form definition: a list of fields, each with a type, label, validation rules and order, saved as structured data such as JSON. The same definition drives both the editor and the public form, so adding a field needs no new code.

How should form submissions be stored?

Save each submission with a reference to the form version it was made against and the answers keyed by field ID. That way renaming or reordering a field later doesn't break old submissions.

How do I stop spam on a public form?

Combine a hidden honeypot field, rate limiting per IP address, server-side validation and, if spam persists, a CAPTCHA service. Never rely on checks that run only in the browser.

Do I need a full form builder or just a form?

If you need one or two fixed forms, build those forms directly — it's much simpler. A form builder is worth it when non-technical people need to create and change many forms without asking a developer.