The trade-off
Why Formulira
There is no shortage of form services. This is where this one differs — and when you are better off with something else.
Your data stays where you want it
Most form services run on servers you do not administer, in a jurisdiction that is not yours. For a newsletter sign-up that is fine. For a job application, an incident report or a customer survey with free-text fields it is not: personal data is going over the wire that you are the controller for, and you have to be able to explain where it sits.
Formulira runs on your server, with your database. There is one outbound connection, and it goes to the translation engine carrying the labels of your questions. The answers people give never leave your machine.
Multilingual forms that do not drift apart
Five separate forms for five languages work until you change something. After that they diverge, and you find out when a German customer gets a question the Dutch one stopped seeing six months ago.
In Formulira there is one form with one set of questions. Every question has a key that is language independent. The translations hang off that key, not the other way round. Add a language and it inherits every existing question; change a question and it changes everywhere.
Exports that still line up years later
This is the mistake most form builders make: the export uses the label as the column header. As long as nobody changes anything, it works. Rename a question from "Name" to "Full name" and from that moment you have two columns that mean the same thing, and your CRM integration breaks without an error.
Formulira uses the field key. It does not change when the question is renamed or translated. An export from today has the same columns as an export from last year, even if the form is three versions further on.
When Formulira is NOT the right choice
Being straight about this matters, because a wrong choice costs you more than it costs me.
- **You need one contact form and nothing else.** This is too much. A form in your existing CMS is quicker and cheaper.
- **You want to take payments in the form.** Not supported, and not planned. Look at a service built for it.
- **Nobody administers your server.** Self-hosting means backing up, patching and monitoring yourself. Without someone to own that, a hosted service is the wiser call, even if your data then lives elsewhere.
- **You only ever need one language.** Then you are paying for a translation layer that sits idle.
When it does fit
If you build forms regularly, in more than one language, with answers you actually process — into a CRM, a report or a workflow. And if you need to be able to explain where those answers live and how long they are kept.
Questions that keep coming up
- How does this compare to Google Forms or Typeform?
They are quicker to set up and have more polish. They also do not run on your server, they have no versioning that keeps old answers attached to their own question set, and their multilingual support amounts to separate copies per language. For a survey among colleagues they are fine; for something embedded in your processes they are not.
- Can I match my own house style?
Yes. Colours, logo and legal entity are configurable per environment, including a neutral variant with no brand name for research where recognition would colour the answers.
- What if I want to move away later?
Your data sits in a MySQL database you administer, and every form exports to CSV or Excel. There is no export button you have to request first.