Branching turns a form from a list into a program, and it inherits the problem programs have: it can be wrong in ways that look right.
The specific failure is not a form that errors. It is a form that renders perfectly, that you tested by clicking through the path you had in mind, and that skips a question for a third of your respondents.
Five operators, on purpose
DevForm's conditions are is, is not, is one of, was answered, was not answered. That is the
list.
The temptation with a logic builder is expressiveness: numeric comparison, string matching, boolean combinators, nested groups. Each addition is individually reasonable and the aggregate is a programming language with a mouse-driven syntax and no debugger.
Five operators is a deliberate ceiling. A branching form you cannot verify by reading it is worse than a linear form you can, and verification-by-reading stops working somewhere around the point you need parentheses. If your logic genuinely needs more than these five, the honest answer is that it needs two forms, or a form and a conversation.
The three mistakes that survive inspection
The builder warns about exactly three things. They are not arbitrary — they are the three that produce a form which reads correctly and behaves wrongly.
A condition referencing a field that no longer exists. You deleted question four; question nine still branches on it. Nothing errors. The condition simply never matches, so question nine either always shows or never does, depending on how it was written. This is the most common of the three and it happens during editing rather than during authoring, which is why nobody is looking for it.
A condition referencing a question that comes later in the form. This is the dangerous one. "Show question three if question seven was answered" reads perfectly when you scan it — you can picture both questions, the relationship makes sense, and it cannot possibly work at runtime because question seven has not been asked yet. One question per screen makes forward references easy to write and impossible to notice, because you are never looking at both questions at once.
A condition referencing itself. Rarer, usually a copy-paste, and instantly broken in a way that is invisible until somebody fills the form.
All three are warnings at build time rather than errors at submit time. The alternative — discovering them from a respondent — means the data is already wrong and you cannot tell which responses are affected.
Test the paths you did not design
The reason branching forms ship broken is that the author tests the path they had in mind. That path works; it is the one the logic was written for.
Enumerate instead. With three yes/no branches you have eight paths and you will have thought about two. Walk the other six. It takes ten minutes and it is the only reliable way to find the question that shows up for a combination you did not picture.
Pay particular attention to the path where somebody answers nothing optional. was not answered
conditions fire there, often in combinations you did not intend, and it is the single most under-
tested route through any branching form.
Branching costs you comparability
The tradeoff nobody mentions when selling logic as a feature.
Every branch splits your dataset. A question asked of everyone gives you one number. The same question asked only of people who said yes to something else gives you a number about that subgroup — smaller, and not comparable to anything.
That is fine when the branch is genuinely irrelevant to the other group. It is expensive when you branched to be polite. Asking "what would make it worth that?" only of people who picked a high price bracket feels considerate and costs you the answer from the people whose objection you most needed.
Before adding a condition, ask whether you are removing a question that does not apply, or removing a question that is merely awkward. The first is what logic is for. The second is how you end up unable to compare anything.
What the logic cannot do
Conditions control whether a question is shown. They do not:
- Calculate anything. No scoring, no totals, no derived fields.
- Validate one answer against another.
- Change a question's wording based on an earlier answer.
- Branch on anything outside the form — no URL parameters, no known respondent, no prior submission.
And the surrounding limits, since they bound what a branching form is for here: no file uploads on any plan, no notification emails, no webhooks, no integrations. Logic starts at Starter, $9/mo; the free plan has none, with 1 form, 10 questions and 100 responses a month.
What you get back
Partial responses are stored from the first answer rather than on submit, and on a branching form that is worth more than on a linear one — abandonment tells you which branch is the problem, and the branch is usually the answer.
A cluster of drop-offs on one path normally means one of three things: that path asks for something people do not have to hand, it asks for something they are not ready to give without knowing why, or the branch put them somewhere that does not make sense given what they just said.
The third is a logic bug you cannot find by reading, and the partial responses are the only place it shows up.