Citizen Developer, echte Infrastruktur: Wenn von Unternehmen entwickelte Apps echtes Hosting brauchen

Der Marketinganalyst hat in Bubble ein Kundenportal erstellt. Die Finanzabteilung nutzt einen Onboarding-Prozess für Lieferanten in Airtable sowie einige Make-Szenarien. Der Betrieb verfügt über eine Glide-App, mit der 40 Außendiensttechniker Serviceeinsätze protokollieren. Nichts davon lief über die IT, und jetzt fragt der CFO, wer verantwortlich ist, falls etwas davon kaputtgeht. Dieser Leitfaden richtet sich an IT-Manager und Agenturpartner, die Produktionssysteme übernehmen, die sie nicht selbst spezifiziert haben, und die eine klare Methode benötigen, um zu entscheiden, wann von Unternehmen entwickelte Apps eine produktionsreife Infrastruktur benötigen.

Was ist ein Citizen Developer, und warum wirft das für die IT eine Frage zur Infrastruktur auf?

Ein Citizen Developer ist jemand, der kein Programmierer ist – meist aus den Bereichen Marketing, Betrieb, Finanzen, Personalwesen oder einem Geschäftsbereich –, der mithilfe von No-Code- oder Low-Code-Plattformen funktionierende Anwendungen erstellt. Tools wie Bubble, Webflow, Glide, Softr, Retool und Microsoft Power Apps ermöglichen es Leuten, die keinen Produktionscode schreiben können, etwas zu veröffentlichen, das wie echte Software aussieht und sich auch so verhält.

Das Wachstum war rasant. Branchenstudien zufolge werden bis 2026 rund 80 % der Low-Code-Nutzer außerhalb der formellen IT-Abteilungen tätig sein, und etwa 79 % der Unternehmen haben innerhalb eines Jahres nach dem Start funktionierende Webanwendungen durch Citizen Development erstellt. Das klingt nach Produktivität. Aus Sicht der IT oder der Agentur bedeutet dies aber auch eine stille Erweiterung des Anwendungsportfolios, für dessen Support du nun verantwortlich bist.

Die Frage nach der Infrastruktur taucht erst später auf. Die Plattform selbst hostet die App. Die meisten Plattformen berechnen bei großem Umfang Gebühren pro Datensatz, pro Nutzer oder pro Workflow, und die meisten haben strenge Beschränkungen hinsichtlich benutzerdefinierter Domains, Dateispeicher, E-Mail-Volumen, API-Ratenbegrenzungen und Datenbankleistung. Sobald eine unternehmensinterne App an Fahrt gewinnt, machen sich diese Beschränkungen bemerkbar, und jemand muss entscheiden, ob man weiterhin die Plattformgebühren zahlt, Teile der Arbeitslast auf ein echtes Hosting verlagert oder die App neu entwickelt.

Wann wird aus einer No-Code-App kein Experiment mehr, sondern ein Produktionssystem?

Es gibt einen Unterschied zwischen einem Tool, das einem Team hilft, schneller zu arbeiten, und einer Anwendung, auf die Kunden, Aufsichtsbehörden oder Einnahmen angewiesen sind. Diese Grenze wird selten bewusst gezogen. Meistens wird sie stillschweigend überschritten, und die Anzeichen dafür sind eher betrieblicher als technischer Natur.

Du hast es mit einem Produktionssystem zu tun, wenn:

• Die App ist im Kundenkontaktbereich im Einsatz. Dazu gehören die Erfassung von Leads, Terminplanung, Zahlungen, Self-Service für Kundenkonten, Supportanfragen und Partnerportale. Wenn die App ausfällt und ein Kunde das bemerkt, handelt es sich um den Produktionsbetrieb.
• Es speichert oder verarbeitet regulierte Daten. Dazu gehören personenbezogene Daten, Zahlungsinformationen, gesundheitsbezogene Daten, Mitarbeiterdaten oder alles, was den Beschränkungen der DSGVO, des CCPA oder des HIPAA unterliegt, sowie vertragliche Datenverarbeitungsklauseln.
• Ein Umsatzprozess hängt davon ab. Auftragsweiterleitung, Rechnungserstellung, Abonnementverwaltung, Provisionsberechnung. Alles, wo Ausfallzeiten direkt zu verzögerten Zahlungseingängen führen.
• Es lässt sich über eine API mit den Stammdatensystemen verbinden. Salesforce, NetSuite, HubSpot, Workday. Bidirektionale Integrationen schaffen eine echte Risikofläche.
• Mehr als eine Abteilung nutzt dieselbe Instanz. Durch abteilungsübergreifende Abhängigkeiten wird aus einem Tool zur persönlichen Produktivität eine gemeinsam genutzte Infrastruktur.
• Es gibt keinen dokumentierten Eigentümer und keinen Plan für die Rücknahme. Das ist ein deutliches Zeichen. Wenn der ursprüngliche Entwickler im Urlaub ist und niemand die App reparieren kann, hat sie das Prototypenstadium hinter sich gelassen.

Wenn zwei oder mehr dieser Punkte zutreffen, behandle die App als Produktionsumgebung. Die Frage nach dem Hosting ist dann nicht mehr optional.

Wo stoßen unternehmensinterne Apps an die Grenzen der Infrastruktur?

Die ersten Probleme scheinen meist nichts mit dem Hosting zu tun zu haben. Formulare werden während der Geschäftszeiten langsam. Webhook-Integrationen brechen ab. Die benutzerdefinierte Domain lässt sich nicht mehr auflösen. Die PDF-Erstellung stockt. E-Mails landen im Spam-Ordner. Jedes einzelne sieht aus wie ein Plattformfehler, aber das eigentliche Problem ist fast immer eines von drei Dingen.

Ressourcenbeschränkungen auf der No-Code-Plattform selbst. Die meisten Plattformen drosseln bei bestimmten Tarifstufen die Ausführung von Workflows, Datenbankabfragen oder die Anzahl gleichzeitiger Nutzer. Die App läuft bei 50 Nutzern noch reibungslos, stößt aber bei 500 an ihre Grenzen. Ein Upgrade des Plattformtarifs kostet oft mehr als die gleiche Kapazität auf einer echten Infrastruktur.

Backend-Logik, für deren Ausführung die Plattform nie konzipiert wurde. Als der Business-Analyst eine „kleine“ Automatisierung hinzufügte, die jede Nacht 10.000 Datensätze verarbeitet, PDF-Dateien mit dem Firmenlogo erstellt, drei externe APIs abfragt und die Ergebnisse per E-Mail versendet, wurde daraus ein Backend-Job. Die Ausführung innerhalb der No-Code-Plattform ist langsam und anfällig. Die Ausführung auf einem Linux-VPS mit einer ordentlichen Job-Warteschlange ist schnell und stabil, aber jemand muss das Ganze hosten.

Externe Abhängigkeiten, die die Plattform nicht verwaltet. Eigene Domains, SSL-Zertifikate, dedizierte IP-Adressen für die E-Mail-Reputation, Dateispeicherplatz über das enthaltene Kontingent hinaus, Datenbank-Backups, die über den Aufbewahrungszeitraum der Plattform hinausgehen. Diese fallen fast sofort aus dem Rahmen der Plattform heraus und müssen irgendwo untergebracht werden.

In dieser letzten Kategorie kommen meist IT- und Agenturpartner ins Spiel. Die App bleibt, wo sie ist. Die Infrastruktur drumherum wird auf einem echten Hosting-Server aufgebaut.

Sollten Apps von Citizen Developers denselben Hosting-Server nutzen wie von der IT entwickelte Systeme?

Im Allgemeinen nicht. Wenn du vom Fachbereich entwickelte Apps mit vom IT-Team entwickelten Apps auf demselben Server mischst, entsteht in deiner eigenen Umgebung das Risiko von „Noisy Neighbors“, und Code, der von Leuten mit unterschiedlichen Fähigkeiten gepflegt wird, befindet sich hinter derselben Firewall wie der Code, den dein Entwicklerteam pflegt.

Das sauberere Modell ist die Isolierung nach Konten oder Umgebungen. cPanel WHM, die in den VPS- und Dedicated-Server-Paketen von InMotion enthalten sind, bieten dir Ressourcenbeschränkungen pro Konto und eine vollständige Dateisystemisolierung zwischen den Workloads. Das bedeutet, dass ein außer Kontrolle geratenes Skript in einer Marketing-App das Kundensupport-Portal, das auf demselben Server läuft, nicht beeinträchtigen kann. Die pro Konto festgelegten Obergrenzen für CPU, Arbeitsspeicher und E/A in WHM sind der Grund, warum Multi-Tenant-Hosting-Anbieter seit zwei Jahrzehnten gemischte Workloads sicher betreiben können, und sie funktionieren genauso gut für den internen Gebrauch.

Für Agenturen, die mehrere Kunden mit No-Code-Produktions-Apps betreuen, lässt sich dieses Modell problemlos skalieren. Jeder Kunde erhält sein eigenes cPanel mit isolierten Ressourcen, isolierten E-Mail-Konten und isolierten Datenbanken. Wenn die App eines Kunden Probleme macht, merken die anderen davon nichts.

Ein paar praktische Tipps:

• Halte die gehostete Laufzeitumgebung der No-Code-Plattform getrennt von allen benutzerdefinierten Backend-Diensten, die du selbst hostest.
• Stell deine Produktions-Backend-Dienste auf einem VPS oder einem Dedicated-Server mit cPanel Root-Zugriff bereit, nicht auf einem Shared-Hosting-Paket, das sie im ungünstigsten Moment drosseln könnte.
• Nutzen Shared Hosting für statische Marketing-Websites, Landingpages mit geringem Traffic und den Frontend-Teil kleiner No-Code-Projekte.

Wie wählt man die richtige Hosting-Lösung für eine unternehmensinterne Anwendung aus?

Die richtige Dimensionierung besteht aus zwei Schritten: die Ermittlung des Arbeitsaufkommens und die Zuordnung zu einem Hosting-Paket, ohne dabei zu viel Kapazität bereitzustellen.

Stell dem Bauunternehmer zunächst fünf Fragen:

1. Was macht die App eigentlich? Nur Frontend oder Frontend plus Hintergrundaufgaben?
2. Wie viele gleichzeitige Nutzer gibt es in Spitzenzeiten? Die tatsächliche Zahl, nicht die Gesamtnutzerzahl.
3. Wie viele Daten und wie sensibel sind sie? Datenvolumen in GB und eine Ja/Nein-Angabe zu regulierten Daten.
4. Mit was lässt es sich integrieren? APIs, Datenbanken, E-Mail-Anbieter, Zahlungsdienstleister.
5. Was kostet eine Stunde Ausfallzeit? Wenn möglich, bitte beziffert.

Diese Antworten zeigen meist, ob es sich um eine geringe, mittlere oder hohe Arbeitsbelastung handelt. Ein internes Tool für 50 Nutzer ohne regulierte Daten und ohne Auswirkungen auf Kunden ist gering. Ein Kundenportal für 500 Nutzer, das Bestellungen verarbeitet, ist hoch. Die meisten Apps liegen irgendwo dazwischen, und genau dort ist die richtige Dimensionierung am wichtigsten. Eine Überdimensionierung auf einen dedizierten Server, obwohl ein Managed VPS die Arbeitslast für ein Viertel der Kosten abdecken würde, ist ein häufiger, teurer Fehler.

Der umgekehrte Fehler kommt teurer zu stehen. Eine kundenorientierte Produktions-App auf einem 5-Dollar-Shared-Hosting-Paket zu betreiben, nur weil der Citizen Developer dort angefangen hat, funktioniert – bis es nicht mehr funktioniert. Der erste Traffic-Anstieg, ein Plugin-Update oder ein Compliance-Audit zwingt zu einer Notfallmigration, meist unter Zeitdruck.

Welches Hosting-Paket eignet sich für welche Art von Workload bei Citizen Developers?

Die folgende Tabelle ordnet tatsächliche Auslastungsmuster den InMotion-Tarifen zu. Dies sind Anhaltspunkte, keine festen Vorgaben. Die tatsächliche Eignung hängt von deinem spezifischen Traffic, deinen Daten und deinem Integrationsprofil ab.

Auslastungsmuster	Empfohlene Stufe	Warum es passt
Statische Marketing-Website oder Landingpage, erstellt mit Webflow, mit einer eigenen Domain bei InMotion	Shared Hosting (Launch oder Pro)	Geringer Ressourcenbedarf, keine Backend-Dienste, die gehostet werden müssen. Die Pro-Version bietet zusätzlich WHM und bis zu 4 cPanel für Agenturen, die mehrere Kundenprojekte verwalten.
No-Code-App mit einem kleinen, maßgeschneiderten Backend (ein oder zwei API-Endpunkte, geringes Datenaufkommen)	Unverwaltete VPS	Root-Zugriff für Node.js-, Python- oder PHP-Dienste. Die Ressourcenisolierung verhindert eine Drosselung bei Shared-Plänen. Läuft auf AlmaLinux 9, Ubuntu 22.04 LTS oder Debian 12.
Ein internes Tool für die Produktion mit 100 bis 500 Nutzern und Anbindungen an Salesforce oder ähnliche Systeme	VPS mit Premier Care	Bietet Monarx-Malware-Schutz, 300 GB Backup-Speicherplatz und APS-Prioritäts-Support für Teams ohne eigenes DevOps-Team.
Kundenorientierte App, die Zahlungen abwickelt oder personenbezogene Daten verarbeitet	Verwalteter dedizierter Server (Essential oder Advanced) mit Premier Care	Hardware für einen einzigen Kunden, 500 GB Backup-Speicherplatz, 1 Stunde Beratung durch InMotion Solutions pro Monat, SLA mit einer garantierten Verfügbarkeit von 99,99 % und Gutschrift bei Ausfall.
Containerisierte Backend-Dienste (Docker) zur Unterstützung eines No-Code-Frontends	Managed-VPS-Paket mit 16 vCPUs	Offiziell Docker-kompatible Managed-VPS-Stufe; geeignet für Queue-Worker, geplante Jobs und Microservices.
Agentur, die 10 oder mehr No-Code-Projekte für Kunden betreut	Pro Shared-Hosting oder Reseller-Hosting	WHM, isolierte cPanel pro Kunde, White-Label-Optionen und klare Abrechnungstrennung.

Für Agenturen bietet das Agentur-Partnerprogramm zusätzlich zum zugrunde liegenden Tarif Provisionen oder Rabatte. Die Stufe, für die du dich qualifizierst (Basic, Recognized, Preferred oder Signature), hängt vom monatlichen wiederkehrenden Umsatz bei InMotion ab – nicht davon, welche Produkte deine Kunden nutzen.

Welche Governance-Maßnahmen sind erforderlich, bevor die IT eine vom Fachbereich entwickelte App für den Produktiveinsatz freigibt?

Die Governance für Citizen-Developer-Apps ist nicht dasselbe wie die Governance für den Code, den deine Entwickler geschrieben haben. Der Entwickler wird sich kein 40-seitiges Dokument zur Architekturprüfung durchlesen. Das Ziel ist eine kurze, wiederverwendbare Checkliste, die ein Marketinganalyst oder ein Betriebsleiter tatsächlich abarbeiten kann.

Ein praktikables Minimum:

• Bestandsaufnahme. Name, Eigentümer, Geschäftszweck, Plattform und Technologie-Stack jeder intern entwickelten App, die derzeit im Einsatz ist. Die meisten Unternehmen sind überrascht, was auf dieser Liste steht, wenn sie sie tatsächlich erstellen.
• Datenklassifizierung. Um welche Art von Daten geht es? Öffentliche, interne, vertrauliche oder regulierte Daten. Regulierte Daten erfordern eine frühzeitige Entscheidung über das Hosting.
• Zugriffsüberprüfung. Wer darf die App bearbeiten, wer darf die Daten einsehen und was passiert, wenn diese Personen das Unternehmen verlassen?
• Sicherung und Wiederherstellung. Wo die Daten der App gespeichert sind, wie oft sie gesichert werden und wie lange die Wiederherstellung dauert. Die standardmäßige Sicherung der Plattform reicht für den Produktivbetrieb selten aus.
• Leitfaden für Störfälle. Zwei Telefonnummern und ein Eskalationspfad. Wen man anrufen muss, wenn die App nicht mehr funktioniert, und wer befugt ist, sie offline zu nehmen.
• Hosting- und Integrationsübersicht. Ein einfaches Diagramm, das die No-Code-Plattform, alle extern gehosteten Dienste und die Systeme, mit denen sie verbunden sind, veranschaulicht.

Für Agenturen wird diese Checkliste Teil des Gesprächs zur Kundenakquise. Sie bietet zudem einen Anlass, laufende Managed Services in Rechnung zu stellen, anstatt dem Kunden einfach nur eine Hosting-Rechnung zu überreichen und sich dann zurückzuziehen.

Wann solltest du eine No-Code-App auf eine herkömmliche Hosting-Infrastruktur migrieren?

Die meisten No-Code-Apps müssen nie umziehen. Sie laufen auf der Plattform, skalieren innerhalb der Grenzen der Plattform und erledigen jahrelang still und leise ihre Arbeit. Eine Migration wird erst dann in Betracht gezogen, wenn eines von vier Mustern auftritt.

Die Plattformkosten steigen schneller als der Wert der App. Wenn die Preise pro Nutzer, pro Datensatz oder pro Workflow auf der No-Code-Plattform die Kosten für eine vergleichbare Kapazität auf einem VPS plus die Zeit eines Entwicklers für die Wartung übersteigen, hat sich das Preis-Leistungs-Verhältnis umgekehrt. Das passiert in der Regel bei 1.000 bis 10.000 aktiven Nutzern, je nach Plattform.

Die Plattform kann die erforderliche Leistung nicht erbringen. Ladezeiten von über 3 Sekunden bei einer kundenorientierten App, API-Antwortzeiten von über 500 ms oder Rückstände bei der Workflow-Ausführung, die kritische Prozesse verzögern. Einige dieser Probleme lassen sich innerhalb der Plattform beheben, andere nicht.

Die Compliance-Anforderungen übersteigen die Möglichkeiten der Plattform. SOC 2 Typ II, HIPAA-Verträge für Geschäftspartner, regionale Datenspeicherung, Anforderungen an die Protokollierung von Audits, Single-Tenant-Bereitstellung. Nicht jede No-Code-Plattform bietet diese Funktionen, und noch weniger bieten sie zu dem Preis, den ein mittelständisches Unternehmen erwartet.

Die App hat sich zu einem langfristigen System of Record etabliert. Wenn eine unternehmensinterne App seit zwei Jahren läuft, klare Verantwortlichkeiten gibt und es unwahrscheinlich ist, dass sie bald ersetzt wird, lohnt sich die technische Investition, sie so umzugestalten, dass sie auf einer echten Infrastruktur gewartet werden kann.

Die Migrationswege variieren je nach Plattform. Webflow exportiert sauberes HTML und CSS. FlutterFlow exportiert Flutter-Code. Bubble exportiert keinen Code, aber seine Daten und Workflows lassen sich auf einem Stack aus Node.js- oder Python-Diensten nachbauen, die PostgreSQL einem VPS mit PostgreSQL laufen. Retool kann auf Docker selbst gehostet werden, was ein Grund dafür ist, dass es den Managed-VPS-Tarif mit 16 vCPU gibt.

Wie können Agenturen Kunden unterstützen, die No-Code-Anwendungen im Produktivbetrieb nutzen?

Agenturen sind für diese Aufgabe besonders gut geeignet, da sie bereits die Schnittstelle zwischen den geschäftlichen Anwendern und der technischen Infrastruktur bilden. Die Kunden, die No-Code-Apps entwickeln, haben in der Regel keine eigene IT-Abteilung, an die sie sich wenden können. Sie haben eine Agentur.

Drei Angebote kommen besonders gut an:

• Hosting plus Governance. Kombiniere Managed Hosting für Backend-Dienste, benutzerdefinierte Domains und E-Mail-Infrastruktur mit einer vierteljährlichen Governance-Prüfung. Berechne eine monatliche Pauschale statt einer Gebühr pro Vorfall.
• Backend-as-a-Service für No-Code-Kunden. Biete eine kleine VPS-Umgebung an, in der die Agentur gemeinsame Backend-Dienste (PDF-Erstellung, E-Mail-Versand, Dateiverarbeitung, geplante Aufgaben) hostet, die die No-Code-App des Kunden über eine API aufruft. Der Kunde erhält Funktionen, die die Plattform nicht bieten kann; die Agentur sorgt für eine konsolidierte Infrastruktur.
• Migrationsbereitschaft. Wenn die App eines Kunden an die Grenzen der Plattform stößt, ist die Agentur, die sich bereits mit der Arbeitslast auskennt, der ideale Partner für die Planung und Durchführung der Neugestaltung.

Der „Pro Shared“-Tarif von InMotion (mit WHM und bis zu 4 cPanel ), das Reseller-Hosting sowie die VPS-Tarife unterstützen diese Arbeit durch isolierte Konten pro Kunde und White-Label-Optionen, wo es darauf ankommt. Das „Agency Partner Program“ bietet Rabatte von bis zu 25 % auf neue und verlängerte Hosting-Verträge der „Signature“-Stufe, wodurch die operative Marge finanziert werden kann, die für die gute Betreuung von No-Code-Kunden erforderlich ist.

Wie sieht eine produktionsreife Infrastruktur für Citizen-Developer-Anwendungen aus?

„Produktionstauglich“ heißt nicht „teuer“. Es heißt „berechenbar“. Die entscheidenden Faktoren, geordnet nach der Häufigkeit, mit der sie zu Störungen führen:

• Isolierte Ressourcen. Ein plötzlicher Anstieg der Auslastung bei einer Anwendung sollte eine andere nicht verlangsamen. Dies wird durch die cPanel bei den Tarifen „Shared Pro“ und „Reseller“ oder durch die vollständige Single-Tenancy auf einem VPS oder dedizierten Server gewährleistet.
• Echte Backups. Nicht nur der Snapshot der Plattform. Off-Server-Backups mit dokumentierter Aufbewahrungsdauer. Premier Care umfasst 300 GB Backup-Speicherplatz auf VPS und 500 GB auf Dedicated-Servern.
• Überwachung und Benachrichtigung. Verfügbarkeitsprüfungen, Überwachung der Reaktionszeiten und Benachrichtigungen bei ablaufenden Zertifikaten. Kostenlose Tools wie UptimeRobot funktionieren; integrierte Tools funktionieren besser.
• Eine schriftlich festgelegte Verfügbarkeitsgarantie. Das mit einer Gutschrift abgesicherte SLA von InMotion mit einer Verfügbarkeit von 99,99 % bietet dir eine solide Grundlage, die du internen Stakeholdern und externen Kunden vorlegen kannst.
• Menschlicher Support, der sich mit der gesamten Infrastruktur auskennt. Die meisten No-Code-Notfälle betreffen DNS, SSL, E-Mail-Zustellbarkeit oder einen falsch konfigurierten Webhook. Echte Support-Mitarbeiter, die rund um die Uhr erreichbar sind, lösen diese Probleme schneller als Chatbots oder Eskalationswarteschlangen.
• Ein Weg zur Skalierung. Wenn die App über ihre aktuelle Stufe hinauswächst, sollte die Umstellung auf die nächste Stufe geplant und nicht in Panik erfolgen. Der Wechsel von „Shared Pro“ zu einem „Managed VPS“ oder von einem VPS zu einem dedizierten Server beim selben Anbieter sorgt dafür, dass DNS, E-Mail und Backup-Tools konsistent bleiben.

Laienentwickler werden weiterhin Produktionsanwendungen entwickeln. Dieser Trend wird sich nicht verlangsamen. Für IT- und Agenturpartner stellt sich die Frage, ob sie dieses Wachstum als unkontrolliertes Risiko betrachten oder als Chance, die Infrastruktur aufzubauen, die diese Anwendungen tatsächlich benötigen.

Wenn dein Team unternehmensinterne Anwendungen betreut und du dir nicht sicher bist, ob dein aktuelles Hosting der Arbeitslast gewachsen ist, kann das Lösungsteam von InMotion die Arbeitslast gemeinsam mit dir durchgehen und dir ein passendes Paket empfehlen. Für Agenturen, die diese Dienstleistung für ihre Kunden bündeln möchten, bietet das Agency Partner Program die zugrunde liegende Infrastruktur, Rabatte und Partner-Support, um das Ganze wirtschaftlich rentabel zu machen.