Für Mittelstand und KMU

Die Entwicklungsplattform für Mittelstand und KMU mit eigener IT

Im Mittelstand läuft die Entwicklung über ein kleines Team und ein gewachsenes Setup. Die Application Platform standardisiert Setup und Betrieb, ohne bestehende Server oder Vorgaben aufzugeben.

  • Eigene Server per SSH oder Managed Server in der EU
  • Audit Log, Rollen und Zugriffsrechte statt gewachsener Zugänge
  • Betriebswissen liegt im Repository, nicht in einzelnen Köpfen

Kostenlos starten. Keine Kreditkarte nötig.

Das Audit Log zeigt, wer wann was geändert hat. Das Audit Log zeigt, wer wann was geändert hat.
Das Audit Log zeigt, wer wann was geändert hat.

Kurz gesagt

Der Engpass im Mittelstand ist selten die Entwicklung, sondern das Drumherum, das niemand dokumentiert hat.

  • Standardisiertes Setup. Repository, Pipeline, Server, Domain und SSL entstehen für jedes Projekt gleich.
  • Eigene Infrastruktur bleibt möglich. Bestehende Server per SSH anbinden oder Managed Server in der EU.

Gewachsenes Setup und standardisierte Plattform

Die Gegenüberstellung beschreibt Aufgaben, die in einem kleinen IT- oder Entwicklungsteam anfallen und über die Jahre unterschiedlich gelöst wurden.

Aufgabe Mit der Application Platform Ohne Plattform
Projekt-Setup Vollständig abgedeckt: Repository, Struktur, CI/CD-Pipeline, Server-Anbindung, Domain und SSL nach einheitlichen Regeln Nicht vorgesehen: Jedes Projekt trägt die Handschrift der Person, die es aufgesetzt hat
Betriebswissen Vollständig abgedeckt: Umgebungen und Deployments liegen als Konfiguration im Git-Verlauf und sind lesbar Nicht vorgesehen: Wissen steckt in Skripten, Wikis mit unklarem Stand und einzelnen Kollegen
Eigene Server nutzen Vollständig abgedeckt: Bestehende Server per SSH anbinden oder Managed Server nutzen Teilweise abgedeckt: Möglich, aber jede Maschine wird einzeln gepflegt
Server-Grundsetup Vollständig abgedeckt: Docker, Datenbanken, Reverse-Proxy, SSL, Firewall und Backups werden automatisch eingerichtet Teilweise abgedeckt: Manuelle Einrichtung, dokumentiert im besten Fall im Nachhinein
Zugriffsrechte und Rollen Vollständig abgedeckt: Organisationen, Rollen und Zugriffsrechte regeln Zugang pro Projekt und Umgebung Teilweise abgedeckt: Berechtigungen sind historisch gewachsen und werden selten aufgeräumt
Nachweise für Audits Vollständig abgedeckt: Audit Log über relevante Änderungen, plus GitOps-Historie für Umgebungen und Deployments Nicht vorgesehen: Nachweise werden für den Prüftermin zusammengesucht
Standort der Verarbeitung Vollständig abgedeckt: Betrieb in der EU, DSGVO-konform, Auftragsverarbeitungsvertrag möglich Teilweise abgedeckt: Einzelne Dienste liegen außerhalb der EU und müssen einzeln bewertet werden
Onboarding und Vertretung Vollständig abgedeckt: Remote-Workspaces mit VS Code, JetBrains, RDP oder VNC starten fertig konfiguriert Nicht vorgesehen: Neue Kollegen brauchen Tage, bis eine Umgebung lauffähig ist
Fehler im Betrieb Vollständig abgedeckt: Error-Tracking mit Sentry mit Stacktrace, Release und Kontext Teilweise abgedeckt: Fehler werden über den Support gemeldet und manuell eingeordnet
Abhängigkeit vom Anbieter Vollständig abgedeckt: Repositories, Pipeline-Konfiguration und Server gehören dem Unternehmen, 100 Prozent Code-Ownership Teilweise abgedeckt: Einzelne Werkzeuge und Dienstleister sind nur mit Aufwand ersetzbar

Grün bedeutet abgedeckt, gelb teilweise, grau nicht vorhanden. Die rechte Spalte beschreibt keinen Wettbewerber, sondern den üblichen Zustand eines über Jahre gewachsenen Setups.

Stand: 10. August 2026. Die Gegenüberstellung beschreibt typische Abläufe und kann je nach Projekt abweichen.

Was ein KMU mit eigener IT davon hat

Punkte, die Betriebssicherheit und Prüffähigkeit betreffen.

Eigene Server bleiben eigene Server

Bestehende Maschinen per SSH anbinden, mit Docker, Reverse-Proxy, SSL und Backups eingerichtet.

Betrieb in der EU

Verarbeitung und Hosting in Europa, DSGVO-konform und mit AVV.

Prüffähige Historie

Audit Log und Git-Verlauf der Umgebungen entstehen als belegbare Spur.

Wissen im Repository

Umgebungen und Deployments liegen als Konfiguration im Git-Verlauf.

  • Anna Weber

    Organisation, Mitglieder & Billing

    Administrator
  • Max Schneider

    Code, Git & Deployments

    Developer
  • Tom Richter

    QA auf Dev & Staging

    Tester
  • Paul Klein

    Kunden-App & Feedback

    Kunde
Rollen und Berechtigungen statt Wissen, das an einzelnen Personen hängt.

So löst du ein gewachsenes Setup schrittweise ab

Ein Projekt als Pilot, danach kontrollierte Ausweitung.

  1. Rahmen klären

    Lege fest, welche Server genutzt werden dürfen, welche Daten wo verarbeitet werden und welche Rollen es geben soll.

  2. Pilotprojekt aufsetzen

    Wähle ein Projekt mit klarem Umfang, lege es im Assistenten an und binde einen bestehenden Server per SSH an.

  3. Standards festschreiben

    Passe die Pipeline-Konfiguration im Repository an interne Vorgaben an. Das Ergebnis dient als Vorlage für weitere Projekte.

  4. Bestand übernehmen

    Bestehende Anwendungen ziehen nach und nach nach, sinnvoll gebündelt mit ohnehin geplanten Updates oder Relaunches.

Häufige Fragen

Müssen wir unsere bestehende Infrastruktur ersetzen?

Nein. Bestehende Server bindest du per SSH an, die Plattform richtet Docker, Reverse-Proxy, SSL und Backups ein.

Wie hilft das bei einem Audit?

Audit Log, dokumentierte Rollen und Umgebungen als Konfiguration im Git-Verlauf liefern die technische Nachvollziehbarkeit.

Was passiert, wenn der Kollege mit dem Wissen ausfällt?

Umgebungen und Deployments sind Konfiguration im Repository statt manuelle Handgriffe. Ein Ausfall blockiert keine Releases.

Starte mit einem Pilotprojekt

Registriere dich kostenlos, lege ein Projekt an und prüfe die Plattform an einem überschaubaren Vorhaben.

Kostenlos starten. Keine Kreditkarte nötig.