survey-creator's licence is per developer, and the Form Library beside it is MIT

The licence is charged per developer, and the file says so in one sentence

The licensing section is the last one in the file, and its first sentence is the whole commercial model: the creator requires a commercial licence for each software developer who works with the APIs or implements the integration.

Per developer, not per deployment and not per form. So the cost of this component tracks the size of your engineering team, not the size of your survey audience. A company with five engineers writing the integration pays for five seats even if a million people fill in the forms.

The next sentence is the exception, and it is cut off. It says you can integrate the component to build a proof of concept and to evaluate its full functionality, which tells you the intended path for the first month and nothing about what happens after that.

Two other signals sit alongside it. The root package manifest does not carry a licence identifier at all; the licence field is a URL pointing at the vendor's licensing page. And the repository's recorded licence metadata reads as unasserted. There is a licence file at the root of the tree as well, whose contents are not reproduced here.

So the terms live on a website rather than in the repository, which is a thing to know before you vendor this into anything you distribute.

The same family ships one MIT library and two commercial ones

The product family section lists five components, and they are not all the same kind of thing.

Two are described as free and open source under the MIT licence: the form library, which renders dynamic JSON based forms and collects responses, and an extractor that pulls answers out of paper forms, PDFs and images and maps them onto the same schema.

Two are commercial. This builder, and the PDF generator that renders surveys to documents in a browser, which is described as allowing an unlimited number of custom built forms with both editable and read only output.

The fifth is a dashboard for visualising and analysing responses with interactive charts and tables, and its licensing is not stated in the section at all.

So the pattern is: the schema and the renderer are free, and the things that generate or transform documents are paid. That is a defensible split, and it explains why the README spends so much effort on the self hosted argument, which the next section covers.

The practical consequence for anyone budgeting is that the JSON definition is the shared contract across all of them. One definition produced in the builder can drive a web form, a PDF and an analytics workflow, and the extractor produces responses in the same shape. So the schema is where the value sits, and the schema is the part you get for free.

It authors forms and does nothing at runtime for the person filling one in

The architecture section makes a narrow claim, and it is worth reading as a contract rather than as marketing.

The builder is a user interface component that you embed in your own application. It is explicitly not a hosted form service, and it does not require a backend from the vendor. You choose the server, the database, the authentication system and the deployment environment.

Then there are four steps, and they are the whole data flow. Save the generated JSON definition to your database. Load it back into the builder when someone wants to edit it. Render it with the separate form library. Store the submitted responses in your own backend.

So the component's job ends when a definition exists. Everything a respondent sees afterwards is rendered by a different library, and everything you store afterwards is your problem. The editor itself runs entirely in the browser.

The file then lists who that suits: applications needing full control over form and response data and integration with existing systems, and both single tenant and multi tenant setups, including configuring the interface differently per role, per tenant or per subscription plan.

That last one is the sharpest hint about the intended market. Per tenant and per plan configuration is a hosting company's problem statement, and it is also the one place where a per developer licence is hardest to reconcile with how the vendor sells.

Four packages, and the development environment expects a second repository beside it

Installation is one package per framework. There is a React package, an Angular package, a Vue package, and one for plain JavaScript, each with its own install line:

npm install survey-creator-react

npm install survey-creator-js

So the choice you make at install time is the framework you have committed to for the editor surface, which is worth deciding carefully, since the editor is the part of the stack that changes most often.

The repository layout explains the rest. There is a workspace configuration file, a packages directory, and a root manifest that is marked private with a placeholder version. So the root is a monorepo container and the four distributable packages live inside it.

The development script is where the cost of that layout shows. It runs several watchers at once, and one of those runs an install script inside a sibling directory at a fixed relative path, which is the separate form library repository.

Which means you cannot get a working development environment from this repository alone. You need to clone the other project next to it, at the expected path, or the first dev command fails on a missing directory.

The repository also carries two Windows batch launchers, one for the React variant and one for a knockout variant, so local startup on Windows is scripted while elsewhere you run the npm script yourself.

The root version is a placeholder and two release lines moved on the same day

The published tags are a 3.1.2, a 2.5.45 and a 3.1.1. So there are two live lines: a current major and a maintenance major.

The timing is the detail worth noting. The 2.5.45 tag was published at 14:22 on 29 September 2026 and the 3.1.2 tag at 14:25 the same day. Two lines of the same product, three minutes apart.

That is a maintenance release and a feature release landing together, which tells you the older line still receives fixes while the newer one moves. For anyone pinned to the 2.5 line it means you get patches without migrating; for anyone on 3.1 it means the 2.5 fixes are not backported forward by default.

Now look at the root manifest. The package is named for the project, marked private, and carries the version 0.0.1.

So the version in the repository root is a placeholder for an unpublished workspace container, and it has no relationship to either release line. Reading the root manifest to find out what version you are running will give you 0.0.1 forever.

The default branch received a push on 2 October 2026, a day before this was assembled, and the archive flag is off.

Installing the development dependencies downloads a browser

The root manifest has a postinstall hook, and it installs a Chromium build for a browser automation library.

That means a plain install of the development tree pulls down a browser binary. For a project with a browser automation test suite that is normal and you would do it anyway. For anyone who installs dependencies in a restricted environment, or on a machine where you would rather not have a second browser, it is a thing to know before the install rather than after.

Two other lifecycle hooks are worth noting. A prepare script installs the git hooks, and there is a separate commit message linter configured with the conventional commits ruleset. So the repository enforces commit message format at commit time, not only in continuous integration.

The pre-push hook runs the lint task and nothing else. Which means the local gate before a push is a lint pass, with zero warnings permitted across the file extensions the project accepts, and no type check and no tests.

That is a light pre-push gate by the standards of most projects of this size, and it puts the weight on continuous integration instead.

Five test suites, one of them for accessibility and one kept for legacy screenshots

The repository root has five test directories, and the names tell you what the project considers a definition of done.

There is an end to end suite, a functional suite, a screenshot suite for visual comparison, a separate legacy screenshot suite, and an accessibility suite.

The legacy one is the interesting entry. Keeping a second screenshot suite alongside the current one means visual regressions against the old interface are still caught while the new one is being established, which is a temporary cost a project usually pays explicitly rather than by accident.

The browser automation configuration is at the root, and there is a separate workflow file for visual regression testing, so visual comparison is a first class pipeline step rather than something a contributor remembers to run.

The accessibility suite as its own directory is the other signal. Form builders produce markup that screen readers and keyboard users have to work with, and the fact that it is a separate suite rather than a few assertions inside the functional tests suggests it is treated as its own problem.

The build badge at the top of the file points at Azure Pipelines rather than at a hosted actions workflow, while the repository also has a dot directory for GitHub. So the continuous integration provider is named explicitly, and there are two places where automation is configured.

Theming is a token mapping problem, and the editor chrome is a preset you export

The customisation story is split into two tools, and the split is the useful part.

The first is a theme editor inside the product, so an author changes colours without touching configuration. The second is a set of theme adapters, in a separate demos repository, which map the builder's design tokens onto other component libraries: Bootstrap, Material UI, or shadcn/ui.

Token mapping rather than a stylesheet means the editor inherits whatever design system the host application already uses, instead of arriving with its own. That is the difference between a builder that looks native and one that looks embedded.

The third tool is the interface preset editor, and it is about the editor's own chrome rather than the form being built. It configures the toolbox, the property grid, tabs, actions and languages, then exports the configuration as a reusable JSON preset.

That export is what makes the per role, per tenant and per plan configuration possible. You build a preset per segment, store it as data, and load the one your current user needs.

Localisation is in the same list: multiple editor languages and right to left support, which for a form builder means the author interface rather than the forms themselves.

Editorial conclusion

survey-creator fits a team that wants non-technical users to author forms and already stores its own data, and it does not fit a team whose cost scales with users rather than with engineers. Three things to settle first. Read the licensing terms properly, because the charge is per software developer who works with the APIs or implements the integration, and the proof of concept carve-out in the file is cut off mid sentence. Decide which package you actually need, since there are four and only one of them matches your framework. And if you are contributing rather than embedding, know that the development environment expects a second repository cloned beside this one.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. surveyjs/survey-creator on GitHub