Wie du einen Formular-Builder baust

Ein Formular-Builder lässt Menschen ihre eigenen Formulare gestalten – Felder auswählen, Regeln festlegen, einen Link veröffentlichen – und sammelt dann die Einsendungen. Im Kern besteht er aus drei Teilen: einer Formulardefinition, die als Daten gespeichert wird, einem Renderer, der aus der Definition ein funktionierendes Formular macht, und einem Speicher für Einsendungen mit Benachrichtigungen und Export. Prüfe vor dem Bauen, ob du überhaupt einen brauchst: Wenn du nur ein Kontaktformular oder ein Bewerbungsformular brauchst, baue dieses Formular direkt und lass den Builder ganz weg.

Brauchst du überhaupt einen Builder?

Ein Builder ist ein größeres Projekt als ein Formular, weil jeder Feldtyp im Editor, im öffentlichen Formular, bei der Prüfung, bei der Speicherung, bei Benachrichtigungen und beim Export funktionieren muss.

Was ein Formular-Builder braucht

Formulardefinitionen

Speichere jedes Formular als Liste von Feldern in strukturierten Daten (JSON in einer Postgres-Spalte funktioniert gut). Ein Feld könnte so aussehen:

• id – eine stabile ID, die sich nie ändert, auch wenn die Beschriftung sich ändert
• type – Text, E-Mail, Zahl, langer Text, Auswahl, Checkbox, Datum, Datei
• label und Hilfetext
• required, min / max, erlaubte Dateitypen
• options für Auswahlfelder
• order und optional eine Bedingung („nur anzeigen, wenn Feld X gleich Y ist“)

Der Editor bearbeitet diese Liste; das öffentliche Formular liest sie. Darin liegt der ganze Trick: kein neuer Code pro Formular.

Einsendungen

• Einsendungen – Formular, Formularversion, Zeitpunkt der Einsendung, Antworten nach Feld-ID, Status (neu, gelesen, archiviert).
• Dateien – hochgeladene Dateien gehören in den Dateispeicher; die Einsendung hält nur einen Verweis, niemals die Datei selbst in der Datenbankzeile.

Seiten

• Formularliste mit Anzahl der Einsendungen.
• Editor – Felder hinzufügen, umsortieren und konfigurieren, mit einer Live-Vorschau daneben.
• Einstellungen – Bestätigungsnachricht oder Weiterleitung, Benachrichtigungs-E-Mails, Öffnungs- und Schließdaten, Limit für Einsendungen.
• Öffentliches Formular unter einem eigenen Link sowie eine einbettbare Version für andere Websites.
• Tabelle der Einsendungen mit Suche, Status, Detailansicht und CSV-Export.

Entscheidungen und Abwägungen

Versionierung. Irgendjemand wird „Telefon“ nach 200 Einsendungen in „Mobilnummer“ umbenennen. Wenn Antworten nach Feld-ID gespeichert und in jeder Einsendung die Formularversion vermerkt wird, werden alte Einsendungen weiterhin korrekt angezeigt. Ohne das werden deine Daten stillschweigend durcheinandergewürfelt.

Prüfung läuft zweimal. Prüfe Felder im Browser für schnelle Rückmeldung und dann erneut auf dem Server, weil jeder Daten direkt an deinen Endpunkt senden kann. Zählt ist die Prüfung auf dem Server.

Datei-Uploads. Sie bringen Speicherkosten, Größenbeschränkungen, Dateitypprüfungen und Datenschutzfragen mit sich (Lebensläufe, Ausweise, medizinische Formulare). Begrenze Typen und Größen und mache hochgeladene Dateien standardmäßig privat, sodass nur die Formularbesitzer sie öffnen können. Siehe wie du Datei-Uploads in deine App einbaust.

Benachrichtigungen. „Schick mir eine E-Mail, wenn jemand einreicht“ wird erwartet. Dafür brauchst du einen E-Mail-Anbieter und einen API-Schlüssel; siehe wie du E-Mails aus deiner App verschickst.

Spam. Ein öffentliches Formular wird von Bots gefunden werden. Nutze ein Honeypot-Feld (für Menschen versteckt, von Bots ausgefüllt), Ratenbegrenzungen pro IP, serverseitige Prüfung und bei Bedarf einen CAPTCHA-Dienst.

Einbettung. Ein iframe ist der einfachste und sicherste Weg, ein Formular auf eine fremde Website zu bringen. Ein Script-Embed wirkt nativer, ist aber schwerer zu bauen und abzusichern.

Bedingte Logik. „Zeige dieses Feld nur, wenn …“ ist beliebt und vervielfacht den Testaufwand. Füge sie erst hinzu, wenn die Grundlagen stabil sind.

Ein erster Prompt, der funktioniert

Baue eine Formular-Builder-Web-App für mein Team. Angemeldete Nutzer erstellen Formulare in einem Editor mit Live-Vorschau. Feldtypen: Kurztext, langer Text, E-Mail, Zahl, Datum, Einfachauswahl, Checkboxen und Datei-Upload. Jedes Feld hat eine stabile ID, eine Beschriftung, einen Hilfetext, ein Pflichtkennzeichen und typspezifische Regeln (Min/Max, Optionen, erlaubte Dateitypen und ein Limit von 10 MB). Speichere die Formulardefinition als JSON mit einer Versionsnummer, die bei jeder Veröffentlichung steigt. Jedes Formular bekommt einen öffentlichen Link und einen iframe-Einbettungscode. Prüfe Einsendungen auf dem Server gegen die veröffentlichte Version, speichere Antworten nach Feld-ID mit der Formularversion und lege hochgeladene Dateien in privatem Dateispeicher ab. Füge ein verstecktes Honeypot-Feld und eine Ratenbegrenzung pro IP hinzu. Formularbesitzer sehen eine Tabelle der Einsendungen mit Status (neu, gelesen, archiviert), eine Detailansicht und CSV-Export. Speichere alles in einer Datenbank. Bedingte Logik und E-Mail-Benachrichtigungen spare dir für später auf.

Build-Schritte

1. Editor und Definition. Baue ein Formular mit jedem Feldtyp und sieh dir das gespeicherte JSON mit dem Agenten an. Ist es sauber und stabil?
2. Öffentliches Formular. Fülle es auf dem Handy aus. Prüfe die Meldungen bei der Validierung und die Bestätigungsseite.
3. Serverseitige Prüfung. Lass den Agenten eine Einsendung, die die Regeln verletzt, direkt an den Server schicken und die Seite umgehen. Sie muss abgelehnt werden.
4. Versionierung. Benenne Felder nach ein paar Einsendungen um und sortiere sie um. Alte Einsendungen sollten weiterhin die richtigen Antworten zeigen.
5. Uploads. Probiere eine zu große und eine Datei mit falschem Typ. Bestätige, dass ein Fremder eine hochgeladene Datei nicht über das Erraten des Links öffnen kann.
6. Tabelle der Einsendungen und Export. Prüfe den CSV-Export mit Kommas, Zeilenumbrüchen und Akzentzeichen in den Antworten.
7. Benachrichtigungen, Einbettung, Logik. Füge sie nacheinander hinzu.

Häufige Fehler

• Antworten nach Beschriftung speichern. Beschriftungen ändern sich. Verwende stabile Feld-IDs.
• Prüfung nur im Browser. Sie ist eine Bequemlichkeit, kein Schutz.
• Öffentlich zugängliche hochgeladene Dateien. Formulare sammeln oft Dokumente, die niemand öffentlich sehen soll.
• Kein Spam-Schutz. Ein öffentliches Formular kann sich innerhalb weniger Tage mit Müll füllen.
• Einen Builder für ein einziges Formular bauen. Baue das Formular.
• Unbegrenzte Einsendungen bei einem öffentlichen Produkt. Wenn Kunden Formulare erstellen, lege Limits pro Tarif fest, sonst kann ein beliebtes Formular deine Hosting-Rechnung in die Höhe treiben.

Wann ein fertiges Produkt die bessere Wahl ist

Gehostete Formulartools sind für die meisten Bedürfnisse hervorragend und günstig. Sie haben Einbettung, Spam-Schutz, Zahlungen, Integrationen und Barrierefreiheit über Dutzende Feldtypen bereits gelöst. Wenn dein Team nur Formulare braucht, nutze eines – siehe Typeform-Alternativen und Google-Forms-Alternativen.

Bau dir eine eigene Lösung, wenn Einsendungen neben deinen eigenen Daten leben müssen (etwa als Anbindung an ein CRM oder ein Kundenportal, das du betreibst), wenn du Workflows nach der Einsendung brauchst, die die Tools nicht können, wenn Speicherort oder Eigentum der Daten eine Vorgabe ist oder wenn Formulare Teil eines Produkts sind, das du verkaufst.

Mit Mythex bauen

Bei Mythex beschreibst du den Builder im Chat und testest Editor und öffentliches Formular in der Live-Vorschau nebeneinander. Mythex legt eine eigene Datenbank für Formulardefinitionen und Einsendungen an und aktiviert den Dateispeicher automatisch, sobald deine App Uploads braucht (im Free-Tarif auf 1 GB begrenzt). Benachrichtigungs-E-Mails laufen über einen Anbieter, den du mit deinem eigenen Schlüssel verbindest. Veröffentliche die App unter einem mythex.ai-Link oder auf Pro unter deiner eigenen Domain; die öffentlichen Formularlinks funktionieren dann von dort.

Fragen