I am going to start with the thing this article cannot do, because it changes how you should read the rest of it.
I have no completion-rate numbers to show you. DevForm is new, nobody has run enough forms through it for a percentage to mean anything, and the internet is full of "single-question forms convert 40% better" claims that trace back to one vendor's blog post about their own customers. Repeating one of those would be borrowing a number I cannot check to sell a product I built.
So: the mechanism, what the product measures, and how to find out for yourself.
What a long form actually asks of someone
Open a fourteen-field form and you make a decision before answering anything: is this worth it?
You make it with the whole thing visible. Every field you have not filled in is in front of you, the scrollbar tells you there are more below, and the two questions you would rather not answer are sitting there being visible. The cost of the entire interaction is presented up front, at the moment the reader has the least investment in it and the least information about why any of it is being asked.
One question per screen inverts that. The decision is now "will I answer this one question", made repeatedly, each time by somebody slightly more committed than the last. It is the same total work. It is not the same sequence of decisions, and people do not evaluate a sequence of small costs the way they evaluate one large one.
There is a second effect that gets less attention and is probably worth more: a question alone on a screen can be written properly. In a fourteen-field grid, every label is squeezed into two words because fourteen sentences would look absurd. Given a screen, a question can have a sentence of context explaining why you are asking — and "why are they asking this" is the actual reason people abandon the awkward field, not the effort of typing.
The honest counter-argument
Single-question forms are worse for some things, and vendors who sell them rarely say which.
Short forms. Three fields on one screen is fine. Splitting them into three screens adds two page transitions to save nobody anything, and it makes the form feel longer than it is.
Forms people fill in repeatedly. If somebody submits the same form weekly, they want the dense grid. They know the fields, they tab through them, and your considerate one-at-a-time flow is now friction they experience every week.
Anything requiring comparison between answers. If question nine only makes sense next to what they put for question four, showing them one at a time hides the thing they need.
Anyone on a bad connection, if the implementation fetches per question. DevForm does not — the questions come down with the page — but plenty do.
The case for one-at-a-time is strongest exactly where most founders need it: a form sent cold to people who have no prior relationship with you, filled in once, where each question needs explaining. Customer research, in other words.
What DevForm records that a form usually does not
A partial response is stored as soon as somebody answers the first question. Not on submit.
That is the feature I would argue hardest for, because it turns the abandoned form from an absence into evidence. The response inbox shows exact counts of complete and unfinished separately, and the unfinished ones tell you where people stopped.
A cluster of abandonment at one question is the most actionable thing a form produces. It usually means one of three things, and you can normally tell which by reading the question again:
- It asks for something they do not have to hand.
- It asks for something they do not want to give you yet, and you have not explained why you need it.
- It is ambiguous, and stopping is easier than guessing.
None of that is visible from a completion rate. It is only visible if the partial answers are stored, which is why they are.
Partials are deleted after thirty days. Somebody who started a form and walked away did not agree to your keeping half their answers indefinitely.
Conditional logic is where forms usually go wrong
The other half of "people finish" is not asking questions that do not apply. DevForm's conditions are
deliberately few — is, is not, is one of, was answered, was not answered — and the
interesting part is not the operators.
It is that the builder warns you about three specific mistakes:
- A condition referencing a field that no longer exists
- A condition referencing a question that comes later in the form
- A condition referencing itself
Every one of those produces a form that looks correct in the builder and behaves wrongly for a respondent — usually by silently skipping a question, or by showing one that makes no sense. Forward references are the nastiest, because the logic reads perfectly when you scan it and cannot possibly work at runtime.
A branching form you cannot verify is worse than a linear one you can. That is the reasoning behind keeping the operator list short: five conditions you can hold in your head beat twenty you cannot.
Answers are checked in the database
Validation runs server-side, against constraints in Postgres, not just in the browser. There are ceilings per response, per network and per form, and they are enforced where they cannot be bypassed by anyone who has opened devtools.
That matters less for the friendly respondent and a lot for the form that gets found by a script. A research form filling up with junk is a research form you stop reading, and the answers you needed are now mixed in with the noise.
What is not there
Being specific, because you will find out anyway:
- No file uploads. Not on any plan. The control is disabled in the builder and the pricing table deliberately omits the row rather than showing four crosses that read as an upsell.
- No notification emails. Nothing is sent when a response arrives. You check the inbox or you export.
- No webhooks, no integrations, no payments, no signatures, no calculations.
If your form needs a document attached, DevForm is the wrong tool today and there is no plan that changes that.
How to get the number I could not give you
Run the comparison yourself, once, on a form you were going to send anyway:
- Build the same questions twice — one screen each, and all on one page.
- Split your traffic. Two links to two forms is enough; you do not need an experimentation platform.
- Compare completes against starts, not against visits. A visit that never answered question one is a landing-page result, not a form result.
- Give it a fortnight and a few hundred starts before you believe either number.
Whatever you find will be about your questions, your audience and your traffic, which is more than any published benchmark can say. If you run it, I would genuinely like to hear the result.