100+ WordPress forms, no form builder

The first WordPress form I built was in 2009. Contact Form 7. The HTML lived inside a textarea in the admin. You’d type the markup and Contact Form 7 would render it.

The form took 90 seconds to build. It worked.

Sometime in the next five years, the industry decided form builders were the future. Drag-and-drop UIs replaced the textarea. Visual logic graphs replaced data attributes. Per-field settings panels replaced HTML attributes you already knew.

I tried builders for two years. I now use them for zero forms. Here’s what changed my mind, after roughly a hundred forms across client sites.

What builders sell you

The pitch:

• “Anyone can build a form, no code required.”
• “Drag fields, set options, publish.”
• “Logic without programming.”

Each of these is technically true. Each is also a mismatch for how forms actually get built and maintained.

What I learned in two years of using them

Forms are 80% layout, 20% logic. A typical contact form has six fields, two conditional rules, one submit handler. The “logic” the builder sells you handles about 90 seconds of total work over the form’s lifetime.

Layout in a builder is slower than HTML. “Add a heading. Set the size. Set the spacing. Open the layout panel. Switch to two-column. Drag the next field next to it. Wait, that’s not how I wanted it. Drag back.” Versus typing <h2>Tell me about you</h2> and <div class="grid">.

Edits in a builder are even slower. A client says “swap these two fields.” In HTML: cut the line, paste it. Two seconds. In a builder: navigate to the field, drag the handle, drop in position, save, check, save again. Twenty seconds.

Builders generate output you can’t read. Open a built form’s HTML in DevTools. It’s wrapped in three nested divs, with builder-specific class names. Your CSS targets are unstable across plugin updates. Performance auditors hate it.

Builders fail at version control. Forms in a builder live in JSON inside the WordPress database. You can’t diff them in git. You can’t review a form change in a pull request. You can’t roll back a “client edited the wrong field” mistake from a backup unless you know exactly which row of wp_postmeta to restore.

These aren’t edge cases. They’re the daily texture of working with builders.

What I do instead

The full workflow:

1. Write the form in HTML. A new Core Form, paste in the markup. Six fields, three minutes.

2. Add data-show-if for conditionals. I covered this in the conditional fields piece. Two attributes, no UI.

3. Wire actions. Email notification, Mailchimp, Notion, Slack, whatever. Each is a 30-second config in the Actions tab.

4. Drop it into the page. Shortcode in classic editor or Gutenberg block in FSE. Done.

Total time for a typical contact form: 8-12 minutes. Including testing.

The same form in a builder: 25-40 minutes. Mostly because the UI is in the way.

Why this scales

When I have 12 client sites with similar contact forms, I have a _template.html file in my notes. New client, copy-paste the template into Core Forms, change two field labels, ship.

Try doing that with a form-builder JSON export. You can’t reliably. The export references the builder’s internal IDs, plugin version, and field schema. Importing into a fresh install often surfaces “this version of the plugin doesn’t support that field type” errors.

HTML is portable. It survives plugin upgrades, theme switches, server migrations. A form I built in 2018 still works in 2026 because the HTML is the same HTML.

What I miss from builders (the honest list)

1. The visual sanity check. A builder shows you a preview as you build. With raw HTML, you have to render the form to see it. The Gutenberg block in Core Forms renders a live preview, so this gap closed for me about a year ago.

2. The “every field has a label” prompt. Builders nudge you to fill in field labels. Writing HTML, it’s easier to forget the <label>. I now have a linter rule that flags input-without-label.

3. The dropdown of field types. “Email field, phone field, address field” — the dropdown reminds you of all the input types HTML supports. With raw HTML, you have to remember <input type="tel"> exists. (Most developers don’t.)

These are real losses. They’re small. They’re worth the tradeoff.

When you’d disagree

If you:

• Build one or two forms a year, not a hundred.
• Don’t write HTML by reflex (you’re a designer or content lead, not a developer).
• Need a non-technical client to edit forms themselves.

Then a form builder probably wins for you. The fastest path is the one you can use without thinking about it.

I write HTML by reflex. So my fast path is HTML. Yours might not be.

What this post isn’t

I’m not saying form builders are bad. I’m saying they’re a productivity tax for the audience that ships a lot of forms. For most agency owners, in-house WordPress devs, and developers building for themselves, that tax is real and worth dropping.

Core Forms ships a form-builder UI for the builder fans. It also ships a “switch to HTML” toggle. You pick the workflow that fits.

The next step

Pick one form on one site that’s stuck in a builder. Look at the rendered HTML in DevTools. Then write the same form in 30 lines of HTML.

Notice which one you’d rather maintain in two years.

For sites that are still on a builder by default, Core Forms is the alternative that doesn’t fight you. The HTML stays HTML.