Where are the survey results?

There are none yet. The survey has not been run. We publish this page as an open invitation rather than fabricating findings, which is the same rule that leaves every product we have not run hands-on unscored.

When will results be published?

When the response count is high enough for the findings to mean something — our threshold is 200 responses — and never before. The changelog will record the date.

What will you publish?

Aggregate findings, the exact question wording, the sample size, the recruitment method and the anonymised raw responses under CC BY 4.0, so anyone can check our reading of the data.

State of Visual Builders 2026: survey open, results not yet published

We are collecting data on how development teams choose and live with visual editor libraries. No results are published here yet, because we have not run the survey — this page is the invitation, not the report.

Updated 2026-09-17

TL;DR

This survey has not been run yet, so this page contains no results. It exists to collect responses, and it will publish findings only when the sample is large enough to be worth reporting.
We are asking about the things nobody has data on: how teams choose an editor, how long integration actually takes, and how often editor projects are abandoned.
When results are published they will carry the sample size, the question wording and the raw anonymised data, because a survey without those is an opinion with a percentage attached.

There are no results on this page

Most "state of" reports in developer tooling are marketing with a chart. They quote percentages without a sample size, recruit entirely from one vendor's mailing list, and publish before anyone could check the arithmetic.

We would rather publish nothing than that. So: this survey has not been run, and this page has no findings. It is the invitation.

What we want to find out

The dataset behind this site can tell you what products exist, how they are licensed and what they weigh. It cannot tell you anything about what happens after a team chooses one, because that data does not exist publicly.

The questions we intend to ask:

How do teams actually choose? Our suspicion, from the questions readers send us, is that most shortlists are assembled from whatever a search returned rather than from requirements — and that the two constraints that matter most (can our customers use it, can it be self-hosted) are usually asked too late.

How long does integration really take? Our calculator estimates 520 hours for a customer-facing editor. That is an estimate built from experience and component parts. We would like to replace it with a distribution from real projects.

How often are editor projects abandoned? Nobody publishes this, and everyone in the category has heard the stories. A number here would be more useful than any feature comparison on this site.

What actually goes wrong? Our hypothesis is that most failures are interaction and scope failures rather than technology failures — the editor works and users cannot use it, or the scope grew until it became a competitor to Webflow. Data would confirm or refute that.

What does the second year cost? Maintenance, upgrades, and the support load an editing feature generates.

What we will publish, and how

When the survey has run and the sample is large enough — our threshold is 200 responses — we will publish:

aggregate findings with the sample size stated in the same sentence as every percentage;
the exact wording of every question, because wording moves answers;
how respondents were recruited, including which channels, because recruitment shapes the sample;
the anonymised raw responses as a downloadable dataset under CC BY 4.0.

If the sample is not large enough, we will say so and publish nothing but the response count. A survey of forty people is a conversation, not evidence.

Why this page exists now

Two reasons.

It is an open invitation: if you have shipped, abandoned or inherited a visual editor integration, your experience is the data. Contact details for participating are on the about page, and the survey link will be published here and in the changelog when it opens.

And it is a marker of how this site works. The methodology page commits us to three rules — measure what we can, source what we cannot, and leave the rest empty. An empty results section on a page that could easily have contained invented percentages is what that rule looks like in practice.

In the meantime

The findings we do have are computed from products rather than people, and they are published in full:

The visual editor library ecosystem in 2026 — what our dataset tells us about the shape of the category.
Bundle size benchmark — measured, reproducible, with the script published.
Time to first editor benchmark — including the mistake we made and corrected.

Frequently asked questions

Where are the survey results?: There are none yet. The survey has not been run. We publish this page as an open invitation rather than fabricating findings, which is the same rule that leaves every product we have not run hands-on unscored.
When will results be published?: When the response count is high enough for the findings to mean something — our threshold is 200 responses — and never before. The changelog will record the date.
What will you publish?: Aggregate findings, the exact question wording, the sample size, the recruitment method and the anonymised raw responses under CC BY 4.0, so anyone can check our reading of the data.

Written by the EditorStack Research Team. How we test and what we refuse to publish is on the methodology page.