Retool oder individuelle interne Software: Drei Jahre Kosten inklusive Wartung

Retool kann auch nach drei Jahren einschließlich Wartung die günstigere Lösung bleiben. Individuelle interne Software kann ebenfalls wirtschaftlicher sein, insbesondere bei vielen Nutzern, stabilen Anforderungen und einem überschaubaren Betriebsaufwand. Aus der Mitarbeiterzahl allein folgt keines der beiden Ergebnisse.

Ein belastbarer Vergleich von Retool und individueller Softwareentwicklung kalkuliert dieselbe funktionsfähige Anwendung, die tatsächlichen Nutzerrollen und identische Serviceanforderungen. Dieser Artikel enthält drei ausdrücklich illustrative Szenarien, ein anpassbares Kostenmodell und eine zusätzliche Migrationsrechnung. Die Zahlen sind Planungsannahmen, keine gemessenen Projektergebnisse, Anbieterangebote oder Preisangebote von Wavect. Die Produktdokumentation wurde am 29. September 2026 geprüft.

Hier geht es gezielt um die Gesamtkosten interner Tools. Die grundsätzliche Entscheidung zwischen Standardprodukt und Individualsoftware behandelt unser Vergleich von Individualsoftware und Standardsoftware. In der vorliegenden Gegenüberstellung erfordern beide Wege Entwicklungsarbeit.

Zuerst dieselbe interne Anwendung vergleichen

Unsere Referenzanwendung ist eine Arbeitsoberfläche für operative Aufgaben: Datensätze suchen, Details öffnen, eine Freigabe anstoßen, einen berechtigten Bericht exportieren und das Aktivitätsprotokoll einsehen. Sie liest aus einer bestehenden SQL-Datenbank und bindet zwei bestehende Geschäfts-APIs an. Sachbearbeitung, Freigabeverantwortliche und Prüfer erhalten unterschiedliche Handlungsmöglichkeiten. Keiner der beiden Ansätze ist ein Kundenportal, ein ERP-Ersatz oder ein KI-Agent.

Die folgende Abnahmebasis bleibt zwischen Retool und Individualentwicklung innerhalb jedes Szenarios gleich. Szenario B erweitert Nutzerkreis und Betriebslast. Szenario C ergänzt Anforderungen an Unternehmensidentität und kontrollierte Releases. Diese Änderungen sind ausdrücklich benannt und werden nicht einseitig für eine günstigere Kalkulation verwendet.

Retool unterstützt Datenbankverbindungen sowie generische REST- und GraphQL-Anbindungen. Retool-Dokumentation zu Datenquellen Das kann technische Verbindungsarbeit reduzieren. Es entscheidet aber nicht, welche Freigabe zulässig ist oder wie eine nur teilweise ausgeführte Geschäftsaktion wiederhergestellt wird. Diese Arbeit gehört in beide Angebote.

Legen Sie auch fest, welche Retool-Generation verglichen wird. Die aktuelle Dokumentation unterscheidet React-basierte Apps von klassischen Apps. Retool: Apps und klassische Apps im Vergleich Unsere Aufwände sind bewusst hypothetisch. Prüfen Sie einen repräsentativen Ablauf in einem technischen Vorversuch, statt einer Variante einen pauschalen Geschwindigkeitsvorteil zuzuschreiben.

Wie gehören Retool-Preise und Nutzerrollen in die Rechnung?

Retool unterscheidet Builder und interne Nutzer; für Enterprise gelten separate Zuweisungsregeln. Die Preistabelle ordnet eigenes SAML/OIDC-SSO und Git-basierte Source Control dem Enterprise-Tarif zu. Retool-Preise und Tarifvergleich Prüfen Sie den tatsächlich gekauften Tarif, statt dessen Sicherheitsumfang aus der Nutzerzahl abzuleiten. Die Self-Service-Fußnoten stufen aktivierte Konten, die im Abrechnungszeitraum erstellen oder bearbeiten, als Builder ein. Die Enterprise-FAQ beschreibt dagegen durch Administratoren zugewiesene Builder und interne Nutzer, die ohne Veröffentlichung erkunden und Entwürfe anlegen dürfen. Bestätigen Sie die Regeln Ihres Vertrags.

In den Szenarien A und B verwenden wir feste illustrative Monatsäquivalente von 50 USD je Builder und 15 USD je internem Nutzer. Das sind Modellwerte, keine garantierten Checkout-Preise bei monatlicher Zahlung. Währung, Zahlungsbindung, Kontoeinstufung, Mindestabnahme, Verlängerung und Funktionsumfang müssen im schriftlichen Angebot bestätigt werden. Für Enterprise verlangt das Modell drei jährliche Angebotssummen, statt einen Sitzpreis zu erfinden.

Zählen Sie personenbezogene Konten ohne Überschneidung: Zwei Builder plus achtzehn interne Nutzer sind zwanzig Personen, nicht zwanzig Endnutzer plus zwei Builder. Berücksichtigen Sie aktivierte Konten, gelegentliche Nutzer, externe Auftragnehmer und technische Identitäten nach dem tatsächlichen Vertrag. Ein Mitarbeiter wird nicht zum externen Nutzer, nur weil ein Portal günstiger wäre. Planen Sie keine gemeinsam genutzten Logins.

Bei mehreren Apps zählt eine lizenzierte Person nach Vertragslogik, nicht automatisch einmal pro Anwendung. Trennen Sie die vollständige Plattformkostenumlage von den zusätzlichen Kosten dieser Anwendung. Eine bereits finanzierte Retool-Umgebung kann die Entscheidung stark verändern. Dasselbe gilt für eine wiederverwendbare eigene Anwendungsplattform. Vorhandene Kapazität macht keine der beiden Plattformen kostenlos.

Das Drei-Jahres-Kostenmodell einschließlich Wartung

Das Modell rechnet ohne Abzinsung in USD und mit einem angenommenen gemischten Stundensatz von 100 USD für beide Alternativen. Es enthält die einmalige Umsetzung und 36 Monate produktiven Betrieb. Jahr eins umfasst die Umsetzung und die Betriebsmonate 1–12. Die Stunden schließen Entwicklung, Review, Tests und Abstimmung ein, nicht nur das Schreiben von Code.

TCO36 = Umsetzung + Lizenzen/Nutzung + Infrastruktur + Wartung + geplante Änderungen + Ausstiegsvorbereitung

Jährliche Self-Service-Lizenz = 12 × (Builder × Builder-Preis + interne Nutzer × Nutzerpreis)

Verwenden Sie die zweite Formel nur, wenn Ihr Vertrag tatsächlich dieser Struktur folgt. Die jährlichen Enterprise-Entgelte heißen Q1, Q2 und Q3 und enthalten vereinbarte Mindestbeträge sowie notwendige Plattformzusätze. Ein unbekanntes Angebot ist unbekannt und nicht null.

Wartung erhält oder stellt vorhandenes Verhalten wieder her: Störungsanalyse, Integrationskompatibilität, verantwortete Abhängigkeiten, Sicherheitsprüfung, Regressionstests und Wiederherstellungsübungen. Geplante Änderungen schaffen neue Funktionen und werden getrennt ausgewiesen. Die Ausstiegsvorbereitung finanziert Dokumentation, ein Verzeichnis relevanter Komponenten und eine kleine Wiederherstellungs- oder Exportprobe, aber keinen vollständigen Ersatz.

Die Szenarien setzen bestehende SQL-, ERP/CRM- und Identitätsanbieter-Abonnements voraus, deren Basislizenzen sich durch keinen Ansatz erhöhen. Die Infrastrukturansätze enthalten zusätzliche Integrations- und Laufzeitdienste, Speicher, Backups und Monitoring. Das Plattformhosting von Retool Cloud wird nicht doppelt berechnet. Beim Eigenbau gehört zusätzlich dessen Anwendungslaufzeit hinein. Arbeitszeit und Infrastrukturentgelte sind getrennte Kosten.

Die Beispiele enthalten keine KI im laufenden Betrieb, kostenpflichtige Workflow-Mehrnutzung, dedizierte 24/7-Bereitschaft oder garantierte Reaktionszeit. Gewöhnlicher Support liegt innerhalb der Wartungsstunden. Steuern, Finanzierung, allgemeine Inflation, Geschäftsausfälle und ungeplante neue Funktionen bleiben außen vor. Ein Budgetansatz ist eine Planungsannahme und keine Kapazitätsgarantie. Ersetzen Sie vor der Beschaffung jeden Schätzwert.

Anpassbare Drei-Jahres-Annahmen als JSON herunterladen. Das Modell enthält Nutzerzahlen, Arbeitspakete der Umsetzung, laufende Stunden, Lizenzannahmen und optionale Migrationswerte. Bewahren Sie beim Anpassen die Unterscheidung zwischen Schätzung und Angebot.

Szenario A: zwanzig Personen und ein klar begrenzter Ablauf

Zwei Builder betreuen die Anwendung für achtzehn interne Nutzer. Die Business-Funktionen erfüllen die festgelegten Anforderungen; eigenes SAML/OIDC-SSO und Git-basierte Retool Source Control sind nicht erforderlich. Beide Umsetzungen brauchen trotzdem individuelle Anmeldung, Rollenprüfungen, Aktivitätsprotokoll und getrennte Testdaten. Kostenpflichtige Mehrnutzung wird nicht angenommen.

Für Retool setzen wir 120 Umsetzungsstunden an: 12 für Discovery, 32 für Oberfläche, 24 für Integration, 16 für Authentifizierung und Autorisierung, 24 für Tests und 12 für Deployment und Übergabe. Beim Eigenbau sind es 280 Stunden über dieselben sechs Pakete: 16, 80, 48, 40, 64 und 32 Stunden. Das sind erfundene Schätzwerte für eine kleine, gut verstandene Anwendung, keine Marktbenchmarks.

Retool ist in dieser Beispielrechnung um 20.680 USD günstiger. Die Lizenz ist nur eine Position: Bereits vier Wartungsstunden pro Monat kosten über den Zeitraum 14.400 USD. Der Vergleich stellt weder Retool als wartungsfrei noch Individualsoftware als supportfrei dar.

Retool bleibt ein sinnvoller Kandidat, wenn der Ablauf passt, das Team das Betriebsmodell akzeptiert und die schnellere Bereitstellung ein ablenkendes internes Plattformprojekt vermeidet. Niedrigere Lizenzkosten des Eigenbaus gleichen ein größeres Umsetzungs- und Wartungsbudget nicht automatisch aus.

Szenario B: drei Builder und 297 interne Nutzer

Dieselbe Arbeitsoberfläche steht nun 300 namentlich erfassten Personen zur Verfügung. Für beide Ansätze erhöhen wir Umsetzung, Wartung und Infrastruktur. Die dargestellte Rechnung ist ein Belastungstest mit Business-Preisannahmen, keine Empfehlung zum Kauf von 300 Self-Service-Lizenzen.

Prüfen Sie zuerst, ob die Identitätsrichtlinie des Unternehmens diesen Tarif tatsächlich zulässt. Verpflichtendes SAML/OIDC-SSO oder Git-basierte Release-Governance führt zum Enterprise-Szenario mit individuellem Angebot. Fordern Sie anschließend ein solches Angebot an, statt diese Hochrechnung als das bestmögliche Retool-Angebot zu behandeln.

Individualsoftware ist unter diesen festen Annahmen um 130.780 USD günstiger. Das ist ein Szenarioergebnis und keine Regel, wonach sich Eigenentwicklung ab 300 Mitarbeitern lohnt. Es setzt voraus, dass die Anwendung ein begrenzter Arbeitsablauf bleibt und nicht zu einem laufend erweiterten Enterprise-Produkt wird.

Retools Zwischensumme ohne Lizenz beträgt hier 52.600 USD. Ein passendes alternatives Angebot unter 35.000 USD für die gesamten drei Jahre würde bei ansonsten unveränderten Annahmen die Kostenreihenfolge umkehren. Das ist ein Angebotsvergleichswert dieses Modells, keine Prognose verfügbarer Enterprise-Preise. Bei geänderter Wartung, Funktionalität oder Sicherheitsanforderung muss neu gerechnet werden.

Szenario C: Enterprise mit kontrolliertem Betrieb und echtem Angebot

Acht Builder und 392 interne Nutzer arbeiten mit der Anwendung. Beide Varianten müssen den vereinbarten Identitätslebenszyklus, SAML/OIDC-Anmeldung, Bereitstellung und Entzug von Zugängen, kontrollierte Releases und Audit-Export unterstützen. Wir setzen Retool Cloud voraus, keinen selbst verwalteten Cluster. Bestehende Lizenzen des Identitätsanbieters bleiben in beiden Fällen unverändert.

Retool erhält 300 Umsetzungsstunden und zehn Wartungsstunden pro Monat, der Eigenbau 480 beziehungsweise sechzehn. Für geplante Änderungen stehen beiden 48 Stunden jährlich zur Verfügung. Der Mehraufwand umfasst die genannten Kontrollen und deren Tests. Retool dokumentiert branchbasierte Änderungen und Pull Requests für Source Control. Retool-Dokumentation zu Source Control Ein Eigenbau muss einen gleichwertigen Prozess bereitstellen und betreiben, nicht bloß ein Repository anlegen.

Verglichen werden 90.800 USD + Q1 + Q2 + Q3 mit 138.600 USD. Nur unter diesen Annahmen ist Retool günstiger, wenn das gesamte Drei-Jahres-Angebot unter 47.800 USD liegt. Ein höheres Angebot rechtfertigt nicht automatisch eine Migration. Prüfen Sie vorher Plattformkostenumlage, Bereitstellungszeit, Betriebsfähigkeit und notwendige Funktionen.

Bei einer vorhandenen Enterprise-Umgebung dürfen für die zusätzliche App nur dann die zusätzlichen vertraglichen Kosten angesetzt werden, wenn die bestehenden Rechte die Nutzer und Nutzung tatsächlich abdecken. Weisen Sie die vollständige Plattformumlage separat aus. Vergleichen Sie keine Retool-Grenzkosten mit einem Eigenbau, dem unverbundene unternehmensweite Gemeinkosten zugeschlagen werden.

Welche Wartung müssen beide Ansätze weiterhin finanzieren?

Hosting und Plattformupdates

Self-Hosting verändert die Zuständigkeit. Retool unterscheidet von Retool betreute und selbst verwaltete Installationen. Bei Letzteren bleibt die Plattformwartung beim Kunden. Retool-Optionen für Self-Hosting Übernehmen Sie die obigen Cloud-Ansätze nicht unverändert in eine selbst verwaltete Installation.

Retools Kostenleitfaden für Self-Hosting betrachtet mehr Infrastruktur als einen einzelnen Anwendungsserver. Retool-Kostenmanagement für Self-Hosting Kalkulieren Sie notwendige Umgebungen, Datenbank, Netzwerk, Monitoring und Backup-Kapazität sowie deren Betreuung. Auch gemanagtes Hosting für Individualsoftware braucht eine klare Aufgabenteilung.

Retool beschreibt geplante Update- und Prüfschritte für selbst verwaltete Installationen. Retool-Planung für Plattformupdates Budgetieren Sie Probelauf, Kompatibilität und Wiederherstellung. Beim Eigenbau müssen gleichwertige Verantwortlichkeiten für Frameworks, Bibliotheken, Datenbank und Betriebssystem namentlich zugeordnet sein.

Authentifizierung ersetzt kein Berechtigungsmodell

Eine erfolgreiche Anmeldung beweist nicht, dass die Person einen bestimmten Datensatz freigeben darf. OWASP empfiehlt minimale Rechte, standardmäßige Verweigerung und Autorisierungsprüfung bei jeder Anfrage. OWASP-Leitfaden zur Autorisierung Für beide Alternativen gilt dieselbe Abnahmebasis.

Testen Sie Freigabeverantwortliche nach einem Abteilungswechsel, Schreibversuche eines Prüfers, entzogene Mitarbeiterzugänge, veraltete Sitzungen und direkte Aufrufe ohne Oberfläche. Zugangsdaten gehören nicht in Browsercode. Greift eine gemeinsame Integrationsidentität auf das ERP zu, muss ausdrücklich geklärt sein, wo die fachlichen Nutzerrechte geprüft werden.

Tests und Änderungen an Integrationen

Retools Testleitfaden für klassische Apps beschreibt manuelle Abläufe und externe Testansätze. Retool-Testpraxis für klassische Apps Codevalidierung und Typprüfung neuer Apps sind separat dokumentiert. Retool-Kontrollen zur Codequalität Weder Typprüfung noch funktionierende Vorschau beweisen die fachlichen Freigaberegeln.

Retool dokumentiert auch WebDriver-basierte Oberflächentests. Retool-Leitfaden für WebDriver-Tests Prüfen Sie, welcher Ansatz zur gewählten App-Generation passt. Individualsoftware benötigt ebenfalls ausführbare Tests, Testidentitäten, vorbereitete Datensätze und eine zuverlässige Deployment-Pipeline. Eine Open-Source-Testbibliothek schreibt diese Tests nicht selbst.

Unser vorgeschlagenes Mindesttestpaket umfasst erlaubte und verbotene Aktionen, doppelte Einreichung, parallele Änderungen, API-Zeitüberschreitungen, abgelaufene Zugangsdaten, geänderte Antwortfelder, fehlgeschlagene Exporte und Wiederherstellung des Anwendungszustands. Binden Sie die Fachverantwortlichen in die Abnahme ein. Nach Änderungen an Oberfläche, Ressourcenrechten oder APIs werden relevante Tests wiederholt.

Leiten Sie Wartungsstunden aus diesem Arbeitsverzeichnis ab. Vier Stunden monatlich sind nur für eine ruhige Anwendung mit wenigen Supportfällen plausibel. Steigende Komplexität bei unverändertem Ansatz ist eine Kalkulationslücke, kein Effizienzgewinn.

Migration: den konkreten Ausstieg kalkulieren, keinen pauschalen Neuaufbau

Retools React-CLI startete am 24. September 2026 als öffentliche Beta. Ankündigung der Retool CLI Deshalb ist die pauschale Behauptung überholt, jede Retool-Anwendung bestehe ausschließlich aus proprietärer Drag-and-drop-Konfiguration.

Klassische Apps lassen sich als JSON oder Toolscript exportieren, allerdings ohne Ressourcen. Retool-Dokumentation zum Export klassischer Apps Die neue CLI unterstützt die lokale Entwicklung Retool-nativer React-Apps und deren Veröffentlichung auf einem Retool-Host. Entwicklungsmodell der Retool CLI Das sind unterschiedliche Ausgangspunkte für Portabilität.

Die Funktionen neuerer Retool-Apps laufen weiterhin auf dessen Backend. Funktionsweise von Retool-Apps Unsere architektonische Schlussfolgerung lautet: Quellcodezugriff beweist keine unabhängige Lauffähigkeit. Erfassen Sie Datenzugriffe, Anmeldung, Ressourcenzugänge, Funktionen, Zeitpläne und Berechtigungen und weisen Sie einen vollständigen Ablauf auf der Ziellaufzeit nach.

Der Wechsel von klassischen Apps zum neuen Builder ist außerdem eine andere Option als der Ausstieg aus Retool. Retool dokumentiert einen internen Konvertierungsweg und fordert Tests des Ergebnisses. Retool-Leitfaden zur Konvertierung klassischer Apps Vergleichen Sie diese Verbesserung mit einem vollständigen Ausstieg, bevor Ersatzsoftware beauftragt wird.

Die Basisbudgets enthalten auf beiden Wegen Ausstiegsvorbereitung. Eine tatsächliche Migration ergänzt zielabhängige Umsetzung, Datenprüfung, Wiederaufbau der Berechtigungen, Umstellung, Schulung und zusätzliche Parallelbetriebskosten. Rechnen Sie wiederverwendbare APIs, Tests und Dokumentation an. Das abgenommene Ergebnis muss auf beiden Wegen gleich bleiben.

Für einen optionalen, vollständig hypothetischen Ausstieg aus Szenario A in Monat 36 nehmen wir beim Retool-Weg 160 Ersatzentwicklungsstunden, 20 Prüfstunden, zehn Stunden für Umstellung und Schulung sowie 1.000 USD zusätzlichen Parallelbetrieb an: insgesamt 20.000 USD. Angenommen, vorhandene Eigenbau-Komponenten reduzieren diese Aufgaben auf 60, zehn und fünf Stunden plus 500 USD: insgesamt 8.000 USD. Das sind Zusatzkosten nach Anrechnung bereits budgetierter Vorbereitung, keine beobachteten Migrationsaufwände.

Mit gewähltem Ausstieg ergeben sich 72.120 USD für Retool und 80.800 USD für Individualsoftware. Selbst in dieser erfundenen Variante bleibt Retool günstiger. Ohne geplanten Ausstieg gibt es keinen verpflichtenden Ersatzaufwand. Eine andere Zielarchitektur, fehlende Unterlagen oder eine größere Anwendungslandschaft können das Ergebnis grundlegend ändern.

Welche Annahmen können das Ergebnis verändern?

Wartung: Zwei zusätzliche Stunden monatlich kosten beim angenommenen Satz über 36 Monate 7.200 USD. Werden sie in Szenario C nur bei Retool ergänzt, sinkt die Angebotsschwelle von 47.800 auf 40.600 USD. Prüfen Sie Supportansätze für Individualsoftware genauso kritisch.

Verlängerungen: Eine illustrative Lizenzerhöhung um jeweils 10 % bei jährlicher Verlängerung verändert die Lizenzsumme in Szenario A von 13.320 auf 14.696,40 USD. Das ist eine Sensitivitätsrechnung und keine Prognose von Retool-Preiserhöhungen. Nutzerwachstum, Tarifwechsel und notwendige Mehrnutzung sind separat zu modellieren.

Bereitstellungszeit: TCO misst nicht den während der Wartezeit entgangenen Nutzen. Schätzen Sie tatsächlich vermeidbare operative Arbeit pro Woche, erwartete Nutzung und den Zeitunterschied zwischen den Varianten. Halten Sie diese Nutzenrechnung getrennt, statt spekulative Produktivitätsgewinne in Softwarekosten zu verstecken.

Plattformpassung: Retool bleibt attraktiv, wenn ein begrenzter Ablauf zu den Kontrollen passt, die Betreuer die Plattform kennen und der gemessene Zeitvorteil zählt. Individualsoftware wird interessant, wenn validierte Anforderungen, wiederverwendbare eigene Dienste oder realistische Kosten die zusätzliche Verantwortung rechtfertigen. Ein Hybrid kann die Retool-Oberfläche beibehalten und dauerhafte Fachregeln über eigene getestete APIs bereitstellen.

Der nächste Schritt ist kein allgemeiner Break-even-Rechner anhand der Mitarbeiterzahl. Es sind eine schriftliche Spezifikation, ein Anbieterangebot, ein repräsentativer technischer Vorversuch und ein Betriebsmodell mit verbindlich geklärter Verantwortung.

Aus dem Vergleich eine Architekturprüfung für interne Tools machen

Bringen Sie den heutigen Ablauf, Nutzer und Rollen, die Zugangsplanung für drei Jahre, die Identitätsrichtlinie, API-Verträge und das gewünschte Supportfenster mit. Bei einer vorhandenen Retool-App ergänzen Sie App-Generation, Betriebsmodell, derzeitigen Vertragsumfang und Beispiele langsamer oder störanfälliger Aufgaben. Teilen Sie bereinigte Unterlagen, keine produktiven Zugangsdaten.

Eine hilfreiche Prüfung liefert eine gemeinsame Abnahmebasis, eine aufgabenbezogene Umsetzungsschätzung, ein durch Angebote belegtes Lizenzmodell, Wartungszuständigkeiten, Test- und Wiederherstellungsplan sowie ein Verzeichnis der für den Ausstieg benötigten Komponenten. Das Ergebnis kann Retool beibehalten, den Tarif anpassen, ein kleines Backend ergänzen oder individuell entwickeln heißen.

Wavects individuelle Softwareentwicklung umfasst klar abgegrenzte interne Anwendungen und Integrationen. Die Fallstudie Bond Analytics liefert angrenzenden Kontext zur Entwicklung von Finanzsoftware, aber keinen Beleg für Retool-Stunden oder Einsparungen dieses Modells. Vereinbaren Sie eine Discovery oder Architekturprüfung für Ihr internes Tool, bevor Sie einen der beiden Wege verbindlich beauftragen.