Um 2026 ein internes Tool zu erstellen, haben Sie vier Wege: eine fertige SaaS-Lösung konfigurieren, es in einer Low-Code-Plattform zusammensetzen, eine Individualentwicklung beauftragen oder es mit einem KI-App-Baukasten generieren. Der Weg ist weniger wichtig als das, was Sie vorher klären: welchen Prozess das Tool abdeckt, welche Daten es speichert und wer was sehen darf. Teams, die diese drei Punkte festlegen, haben in Tagen ein funktionierendes Tool. Teams, die sie überspringen, bauen dieselbe Tabelle nur mit hübscherer Oberfläche neu.
Die Frage betrifft längst nicht mehr nur die IT-Abteilung. Im Build-vs-Buy-Report 2026 von Retool, einer Umfrage unter 817 Entwicklern und Buildern, hatten 35 % bereits mindestens ein SaaS-Produkt durch ein selbst gebautes Tool ersetzt, und 78 % wollten dieses Jahr mehr bauen. Dieser Leitfaden beantwortet die Fragen, die dabei aufkommen: Was zählt als internes Tool, wann sollte aus einer Tabelle eines werden, welcher Weg passt zu welchem Team, und wie kommen Sie von einem Prozess zu einem Tool, das Ihre Kolleginnen und Kollegen wirklich nutzen?
Was ist ein internes Tool? Beispiele nach Team
Ein internes Tool ist Software, die ein Unternehmen für die eigenen Mitarbeitenden baut oder konfiguriert, nicht für seine Kunden: das Back-Office hinter der Website, der Bildschirm, auf dem der Support eine Erstattung auslöst, die Übersicht, die der Betrieb jeden Morgen öffnet. Es hat wenige Nutzer, oft fünf bis zweihundert, aber diese verbringen Stunden darin, und es bildet Regeln ab, die sonst nirgends stehen: wer einen Rabatt freigibt, ab wann eine Bestellung als verspätet gilt, welche Felder Pflicht sind, bevor ein Vorgang weiterläuft.
Die meisten beginnen auf dieselbe Weise: als Tabelle, als gemeinsames Postfach oder als Papierformular, das irgendwann jemandem zu mühsam wird.
| Internes Tool | Was es ablöst | Wer es nutzt | Eine sinnvolle erste Version |
|---|---|---|---|
| Admin-Bereich oder Back-Office | Direkte Änderungen in der Datenbank, Anfragen an Entwickler | Support, Betrieb | Kundendatensätze suchen, ansehen und korrigieren |
| Individuelles CRM oder Vertriebs-Pipeline | Eine gemeinsame Tabelle plus E-Mail-Verläufe | Vertrieb, Kundenbetreuung | Kontakte, Deals, Phasen, nächste Aktion |
| Freigabe-Workflow | E-Mail-Ketten und unterschriebene PDFs | Führungskräfte, Finanzen | Antragsformular, genehmigen oder ablehnen, Verlauf |
| Lager- oder Bestandsverwaltung | Eine Tabelle, die nur eine Person versteht | Lager, Einkauf | Artikel, Bewegungen, Warnung bei niedrigem Bestand |
| Betriebs-Dashboard | Der Montagsbericht per Copy-and-paste | Teamleitung, Management | Fünf Kennzahlen, die sich von selbst aktualisieren |
| Außendienst- oder Einsatzverwaltung | Papierformulare, Fotos im Gruppenchat | Techniker, Disposition | Aufträge, Status, Fotos, Unterschriften |
| Kunden- oder Partnerportal | Status-Mails und geteilte Ordner | Kunden, Lieferanten | Login, die eigenen Datensätze, Dokumente |
Dieselbe Umfrage zeigt, wo Unternehmen anfangen. Unter den Teams, die ein SaaS-Produkt ersetzt haben, wurden am häufigsten Workflow-Automatisierungen (35 %), interne Admin-Tools (33 %), BI-Dashboards (29 %) sowie CRMs und Formular-Builder (25 %) selbst nachgebaut. Der CRM-Fall ist so verbreitet, dass wir ihm einen eigenen Leitfaden gewidmet haben: ein individuelles CRM bauen.
Wann sollte aus einer Tabelle ein internes Tool werden?
Tabellen sind das erfolgreichste interne Tool, das je ausgeliefert wurde, und nichts hier spricht dafür, alle abzuschaffen. Das Problem beginnt, wenn eine Datei unbemerkt zum führenden System wird. Die Forschung zu Tabellenfehlern von Ray Panko an der University of Hawaii, die Praxisprüfungen operativer Tabellen zusammenträgt, fand in 88 % der 113 seit 1995 geprüften Tabellen Fehler. Die Fehlerquote pro Zelle ist niedrig. Doch eine große Datei vervielfacht sie, und nichts in einer Tabelle fängt einen falschen Wert ab, bevor jemand danach handelt.
Fünf Signale zeigen, dass die Datei ihre Grenzen erreicht hat. Mehr als drei Personen bearbeiten sie, sodass Versionen und überschriebene Zellen auftauchen. Jemand sollte nicht jede Zeile sehen, etwa eine Gehaltsspalte oder die Kunden einer anderen Region, und der einzige Schutz ist ein ausgeblendetes Blatt. Ein Blatt enthält Formeln, die niemand anzufassen wagt. Sie müssen wissen, wer einen Wert wann geändert hat, und die Datei kann es nicht sagen. Oder die Daten werden in ein anderes System erneut eingetippt, weil nichts die beiden verbindet. Ein Signal ist lästig. Bei zwei oder mehr arbeitet die Tabelle bereits als internes Tool, nur ohne die Sicherungen. Dann führt Sie unser Leitfaden, wie Sie eine Tabelle in eine App umwandeln, Schritt für Schritt durch die Migration.
Bauen, kaufen oder generieren: vier Wege zu einem internen Tool
Bauen oder kaufen war früher eine Entscheidung zwischen zwei Möglichkeiten. Low-Code-Plattformen machten vor zehn Jahren drei daraus, und KI-App-Baukästen brachten einen vierten Weg: Sie beschreiben das Tool und erhalten eine funktionierende Anwendung. So schneiden die vier bei einem typischen Tool mit 20 bis 50 Nutzern ab.
| Weg | Erste Version | Typische Kosten | Wer baut es | Was Ihnen gehört | Am besten für |
|---|---|---|---|---|---|
| Fertiges SaaS, konfiguriert | Tage | Abo pro Nutzer, oft 10 bis 50 $ pro Nutzer und Monat | Ein Admin im Team | Ein Datenexport, nicht das Tool | Standardprozesse: Lohnabrechnung, Helpdesk, Buchhaltung |
| Low-Code-Plattform (Retool, Appsmith, Budibase, Softr) | Tage bis Wochen | Pro Builder und pro Endnutzer, jeden Monat | Ein Entwickler oder eine technisch versierte Person aus dem Betrieb | Ihre Datenbank; die App liegt auf der Plattform | Oberflächen auf Daten, die Sie schon haben |
| Individualentwicklung | 4 bis 12 Wochen für ein klar umrissenes Tool | Fünfstellig zu Beginn, danach etwa 15 bis 20 % pro Jahr für die Wartung | Entwickler, intern oder Agentur | Alles, Wartung inklusive | Tools, die ein Wettbewerbsvorteil sind |
| KI-App-Baukasten | Stunden bis Tage | Ein Pauschalabo ab etwa 20 $ im Monat, in Credits gemessen, nicht pro Nutzer | Die Person, die den Prozess kennt | Quellcode und Datenbank, wenn das Tool beides exportiert | Maßgeschneiderte Tools, wenn kein Entwickler verfügbar ist |
Die Rechnung pro Nutzer
Für die Preisgestaltung haben interne Tools eine heikle Eigenschaft: viele gelegentliche Nutzer. Laut der öffentlichen Preisliste von Retool im September 2026 kostet der Team-Tarif bei jährlicher Abrechnung 10 $ pro Builder und 5 $ pro internem Nutzer im Monat, und Audit-Logs mit feinen Berechtigungen gibt es erst im Business-Tarif, für 50 $ pro Builder und 15 $ pro internem Nutzer. Bei zwei Buildern und vierzig Kolleginnen und Kollegen sind das 220 $ im Monat im Team-Tarif und 700 $ im Business-Tarif. Der Team-Tarif von Airtable kostet 20 $ pro Bearbeiter und Monat, und die Airtable-Alternativen, die dieses Modell umgehen, vergleichen wir in einem eigenen Leitfaden. Für das, was diese Produkte leisten, ist nichts davon unangemessen. Es bedeutet aber, dass die Kosten eines Tools mit seiner Verbreitung wachsen, das Gegenteil dessen, was Sie von etwas wollen, das das ganze Unternehmen erreichen soll.
Was KI verändert hat und was nicht
KI hat die Anfangskosten einer ersten Version drastisch gesenkt. Den Rest hat sie nicht angetastet: Jemand muss das Tool trotzdem verantworten, es anpassen, wenn sich ein Prozess ändert, und für die Daten darin geradestehen. Die Retool-Umfrage ist hier ernüchternd. 51 % der Befragten haben mit KI Software in Produktion gebracht, und etwa die Hälfte davon spart sechs Stunden oder mehr pro Woche. Doch nur 31 % kommen per Prompt zu vollständigen Anwendungen, und nur 8 % übernehmen KI-generierten Code unverändert. Generierung ist ein Ausgangspunkt, den Menschen prüfen, kein Automat.
Ein internes Tool in sechs Schritten erstellen
Die Methode ist für jeden Weg dieselbe. Die ersten drei Schritte erzeugen Dokumente, keine Software, und hier sollte der größte Teil der Zeit hineinfließen.
Schritte 1 bis 3: erst entscheiden, dann bauen
- 1. Einen Prozess auswählen. Nicht „Betrieb“, sondern „eine Bestellanforderung, von der Erstellung bis zur Zahlung“. Schreiben Sie ihn auf einer Seite auf: wer ihn startet, was danach passiert, was schiefgehen kann, wann er abgeschlossen ist. Wenn Sie diese Seite nicht schreiben können, behebt das kein Tool.
- 2. Das Datenmodell aus Ihren bisherigen Spalten zeichnen. Listen Sie auf, was Sie verfolgen (Anforderungen, Lieferanten, Freigaben) und was Sie zu jedem festhalten. Eine Tabellenzeile, die den Lieferantennamen vierzigmal wiederholt, wird zu zwei verknüpften Tabellen. Drei bis sechs Tabellen decken die meisten ersten Versionen ab.
- 3. Die Rollenmatrix schreiben. Eine Zeile pro Rolle, eine Spalte pro Tabelle: darf sehen, darf anlegen, darf bearbeiten, darf freigeben. Zehn Minuten an diesem Raster verhindern die teuerste Fehlerklasse, nämlich dass jemand sieht, was er nicht sehen soll.
Schritte 4 bis 6: bauen, testen, übergeben
- 4. Die kleinste Version bauen, die die Aufgabe erfüllt. Eine Liste, eine Detailseite, ein Formular, der Statuswechsel. Noch keine Berichte und keine Benachrichtigungen. Mit einer Low-Code-Plattform oder einem KI-Baukasten ist das eine Sache von Stunden, und die Beschreibung aus den Schritten 1 bis 3 ist der Prompt.
- 5. Eine ganze Woche mit drei echten Nutzern testen. Echte Daten, echte Fristen, die alte Tabelle schreibgeschützt eingefroren. Sammeln Sie jede Beschwerde in einer Liste. Rechnen Sie damit, dass sich das Datenmodell einmal ändert: Dafür ist der Pilot da.
- 6. Übergeben. Benennen Sie eine verantwortliche Person. Legen Sie den Code in ein Repository, falls es Code gibt, planen Sie Datenbank-Backups ein und halten Sie fest, wie man einen Nutzer hinzufügt. Ein Tool, das niemandem gehört, ist eine Tabelle mit Login-Seite.
Vier Prüfungen, bevor sich das ganze Team darauf verlässt
Aus einer Demo wird ein Tool an dem Tag, an dem die Leute aufhören, ihre Daten zur Sicherheit noch einmal separat abzulegen. Vier Prüfungen entscheiden, ob es dieses Vertrauen verdient.
| Prüfung | Die Frage | Warum sie wichtig ist |
|---|---|---|
| Berechtigungen in der Datenbank | Wenn ich die API mit einem normalen Konto aufrufe, kann ich Zeilen lesen, die der Screen ausblendet? | Filter in der Oberfläche sind Kosmetik. Regeln müssen dort liegen, wo die Daten liegen |
| Verlauf | Sehe ich, wer diesen Datensatz wann geändert hat? | Streit und Fehler werden durch den Verlauf geklärt, nicht durch Erinnerung |
| Integrationen | Wo liegen die API-Schlüssel, und was passiert, wenn das andere System ausfällt? | Schlüssel im Browser-Code sind öffentlich, und stille Fehler beschädigen Daten |
| Eigentum | Was bleibt uns, wenn der Anbieter verschwindet oder den Preis verdreifacht? | Betriebsdaten sind das Letzte, was sich ein Unternehmen leisten kann zu mieten |
Es gibt eine fünfte, leisere Prüfung: Sagen Sie der IT Bescheid. In der Retool-Umfrage hatten 60 % der Builder im vergangenen Jahr etwas außerhalb der IT-Aufsicht erstellt, meist weil es schneller ging. Tempo ist ein berechtigter Grund. Ein Tool mit Kunden- oder Mitarbeiterdaten muss aber auf irgendjemandes Liste stehen, mit Verantwortlichem, Backup und Zugriffsprüfung, bevor es kritisch wird und nicht erst danach.
Bei Cadrant ist dieser Ablauf das, worum das Produkt gebaut ist. Sie beschreiben den Prozess, und die Plattform generiert eine React-Anwendung, die mit einer PostgreSQL-Datenbank in Ihrem eigenen Supabase-Projekt verbunden ist, mit Tabellen, Relationen und Indizes, die aus Ihrer Beschreibung abgeleitet werden. Die Authentifizierung läuft über Supabase Auth mit eigenen Rollen wie Admin, Editor und Leser. Einfache Row-Level-Security-Richtlinien entstehen aus Ihrem Prompt, und die Dokumentation empfiehlt, sie vor dem Produktivbetrieb in Supabase zu prüfen, also die erste der vier Prüfungen oben. Integrationen laufen serverseitig in Edge Functions, die Schlüssel liegen als Umgebungsvariablen, und ab dem Pro-Tarif wird der Code mit einem GitHub-Repository synchronisiert, für 40 $ im Monat, egal wie viele Kolleginnen und Kollegen das Tool nutzen. Die Details stehen auf der Seite zum Baukasten für interne Tools.
- Ein internes Tool erzwingt Ihren Prozess, eine Tabelle speichert ihn nur. Zwei der fünf Signale genügen für den Wechsel.
- 2026 gibt es vier Wege: konfiguriertes SaaS, Low-Code-Plattform, Individualentwicklung, KI-App-Baukasten. Vergleichen Sie sie nach den Kosten bei voller Verbreitung und danach, was Ihnen bleibt, wenn Sie gehen.
- Prozess, Datenmodell und Rollenmatrix kommen zuerst, und sie lassen sich auf jeden Weg übertragen.
- Prüfen Sie vor dem Rollout die Berechtigungen auf Datenbankebene, den Verlauf, die Integrationen und das Eigentum.