A completion rate is a single number describing a population you know nothing about. 43% finished. Which 43%? Where did the rest stop? What had they already told you?
Partial responses answer all three, and the difference between a form product that keeps them and one that does not is larger than any feature comparison suggests.
Stored from the first answer, not on submit
DevForm writes a partial response as soon as somebody answers question one. The response inbox reports complete and unfinished counts separately, as exact numbers rather than a percentage.
The consequence: the answers people gave before leaving are yours. Somebody who answered four questions and abandoned at the fifth has told you four things. On a form that only stores completions, those four things do not exist.
For customer research that is often the majority of your data. The people who abandon are systematically different from the people who finish — busier, more sceptical, less invested — which makes them exactly the group you most want to hear from and the one a completion-only form silently discards.
Three reasons people stop, and how to tell them apart
A cluster of abandonment at one question means one of three things. Reread the question and it is usually obvious which.
They do not have it to hand. Anything requiring a number they would have to look up, an exact date, a figure from a system they are not logged into. The fix is to make it optional, accept a range, or move it after the questions they can answer from memory.
They are not ready to give it. Email, phone number, company name — asked before you have said why you need it or given them a reason to trust you with it. The fix is ordering and one sentence of explanation, not removal.
It is ambiguous. They cannot tell what you are asking, and stopping is easier than guessing. This is the most common and the easiest to fix, and you can only see it because the drop-off is on one specific question rather than spread.
There is a fourth pattern that is not a question problem at all: abandonment spread evenly across the whole form. That means the form is too long, and no individual question is at fault.
The two clusters that mean something specific
Drop-off at question one. Not a form problem. People arrived, read the first question, and left — which is about whatever brought them there, not about the form. If your first question is reasonable and nobody answers it, the promise on the page before it is wrong.
Drop-off immediately after a branch. On a form with conditional logic this is the interesting one, because it usually means the branch sent somebody somewhere that does not follow from what they just said. That is a logic bug, it does not throw an error, and the partial responses are the only place it is visible.
DevForm's builder warns about the three conditions that produce forms which read correctly and behave wrongly — a condition on a deleted field, one on a question that comes later in the form, and one on itself. Those are caught before publishing. A branch that is valid and merely wrong is caught here, by the abandonment.
What partials cost you
Two things, and they are worth stating.
Storage of answers people did not choose to submit. Somebody who typed two answers and closed the tab did not press a button. DevForm deletes partials after thirty days, which is the compromise: long enough to read the pattern, short enough that abandoned data does not accumulate indefinitely.
A tempting misuse. Partial responses contain contact details somebody entered and did not submit. Treating those as leads is a different thing from treating them as research, and it is the kind of decision that should be deliberate. My view is that an unsubmitted form is not a signup. Yours may differ; make it consciously.
The number to watch instead of completion rate
Answers per start. Total questions answered, divided by number of people who answered at least one.
Completion rate is binary and hides everything. Answers per start moves when your form gets better in ways completion rate does not register — a form where people used to leave at question three and now leave at question seven has not improved its completion rate at all, and has roughly doubled its value to you.
Track it per question too, which gives you the drop-off curve directly.
What is not here
No analytics beyond the counts and the responses themselves. No funnel visualisation, no time-per- question, no heatmaps, no session recording of the form. The inbox shows fifty rows a page with exact complete and unfinished counts, and CSV export streams by keyset.
That last detail matters more than it sounds. PostgREST caps a query at 1,000 rows by default, and a
select meaning "everything" silently returns the first thousand — no error, a file that downloads
and looks correct. It truncated an export in this codebase before anyone noticed, which is why the
export streams rather than pages.
Also not built, on any plan: file uploads, notification emails, webhooks, integrations, payments. You will not be told when a response arrives.
Plans
Free is 1 form, 10 questions, 100 responses a month, no logic and no export. Starter at $9/mo adds logic, embedding and CSV: 5 forms, 30 questions, 2,500 responses. Partial responses are stored on every plan, including the free one — they are not an upsell, because a form product that only kept completions would be throwing away the more interesting half of the data.