← Back
[W] Writing

A form's only job is to not lose the message

A while ago, the line next to Ikiform on my site said "Build Forms, Collect Responses & Analyze." That describes every form tool ever made.

On October 17, 2026 I started a new repo. Today the homepage says something very different.

The Ikiform homepage, with the headline: Your server goes down. Your leads wait.
Ikiform now. It's a backend for any form, and no longer a form builder.

The change came down to one question. What's the worst thing a form can do?

Being ugly isn't it, and neither is missing a feature. The worst thing a form can do is lose someone's message while telling them it arrived. They think they've contacted you. You never hear about it. Neither of you ever finds out.

Save first

So there's one rule underneath the product, and every other feature has to work around it. The submission is saved before anything else gets a chance to fail.

  1. Saved before anything else
  2. Emailed to you
  3. Sent to your webhook
  4. Retried for about 3 days
Your server can be down for a whole weekend, and the message still exists.

Once you hold on to that rule, a lot of smaller questions answer themselves.

What if the workspace goes over its limit? Most tools would reject the submission, because that's the simple way to enforce a plan. Ikiform holds it instead. It's stored and hidden until the plan changes, because the person who filled in the form did nothing wrong.

What gets retried? Each delivery keeps the exact bytes of its first attempt, and every retry and replay sends those same bytes. A webhook signature covers the exact body, so anything rebuilt later could stop verifying, or quietly differ from what happened at the time. When you replay something, it should be the real thing.

Don't lie to the person filling it in

The most interesting decision is what to do when a form isn't paid for yet.

You can test Ikiform for free and pay when real traffic arrives. So what happens when a real visitor submits a form on a workspace with no plan?

Two ways to answer them
The easy one
"Thanks, your message was sent." The owner may never pay, so it may never arrive.
What Ikiform says
"This form isn't live yet. Your submission was saved and will reach the site owner once they activate the form."
The second wording is longer and a bit awkward, but it's true, and it's only true because the submission really was saved.

It's a detail almost no one will see, and I'd still fight for it. A form that lies once can't be trusted again.

The owner gets one email, ever, saying a real submission arrived and is waiting. One. I'm not going to nag people about it.

The headline that got the most clicks

I had the same problem with the headline. I tested six, using 100 simulated buyers. They're AI personas and not real people, so I treat the result as a hypothesis until real traffic backs it up. It was still a useful way to think.

Would click, of all 100 simulated buyers
The backend for every form.52
Your server goes down. Your leads wait.37
Would click, of the 24 who'd pay
The backend for every form.7
Your server goes down. Your leads wait.14
The clear headline got the most clicks, mostly from the people who would never buy. And all 12 of the buyers who'd been burned before picked the other one.

The clearer headline explained the product well, but it gave no one a reason to switch. The other one named the fear, the same one the whole product was built around. It did lose on clarity, so "a form backend for any form" moved into the line underneath.

I liked that this came back to the same idea as the architecture. People don't buy a form backend because they want a form backend. They buy it because they've lost a message before, and they don't want to lose another.

Start with the worst thing your product could do, and design backwards from there. You'll get a better product, and probably a better headline too.

Next