Jedes Projekt startet gleich
Struktur, Konventionen und CI/CD-Pipeline kommen aus vorbereiteten Templates, sodass der Wechsel zwischen Kundenprojekten keine neue Einarbeitung erfordert.
Für Agenturen
Die Entwicklungsplattform für Agenturen mit vielen Kundenprojekten
In einer Agentur laufen mehrere Projekte parallel, jedes mit eigener Domain, eigenen Zugängen und eigenem Server. Die Application Platform legt dieses Grundgerüst automatisch an.
- Jedes Kundenprojekt startet mit demselben Setup
- Mehrere Marken aus einer Codebasis über Whitelabel-Projekte
- Rollen, Zugriffsrechte und Audit Log pro Organisation
Kostenlos starten. Keine Kreditkarte nötig.
Kurz gesagt
Agenturarbeit ist Wiederholung mit Variationen. Genau dort setzt die Plattform an.
- Wiederkehrendes Setup entfällt. Repository, Pipeline, Server-Anbindung, Domain und SSL entstehen beim Anlegen.
- Whitelabel-Projekte erzeugen aus einer Codebasis mehrere Marken mit eigenen Domains und Store-Einträgen.
Agenturalltag mit und ohne Plattform
Die Gegenüberstellung beschreibt typische Aufgaben in einer Agentur, die mehrere Kundenprojekte gleichzeitig betreut.
| Aufgabe |
Mit der Application Platform
|
Ohne Plattform |
|---|---|---|
| Projekt-Setup | Vollständig abgedeckt: Repository, Struktur, CI/CD-Pipeline, Server-Anbindung, Domain und SSL aus dem Assistenten | Nicht angeboten: Jedes Kundenprojekt beginnt mit Grundarbeit, die niemand abrechnen möchte |
| Wiederverwendbare Grundlage | Vollständig abgedeckt: Templates für Next.js, NestJS, Laravel, FastAPI, Flutter, Expo, native Apps, Astro und Hugo | Teilweise abgedeckt: Ein internes Boilerplate, das jemand pflegen muss und trotzdem veraltet |
| Mehrere Marken aus einer Codebasis | Vollständig abgedeckt: Whitelabel-Projekte mit eigenem Branding, eigenen Domains und eigenen Store-Einträgen | Nicht angeboten: Kopierte Repositories, die nach wenigen Monaten auseinanderlaufen |
| Zugriffsrechte pro Kunde | Vollständig abgedeckt: Organisationen, Rollen und Zugriffsrechte trennen Projekte und Teams voneinander | Teilweise abgedeckt: Zugänge liegen verteilt in Passwortlisten und persönlichen Accounts |
| Nachvollziehbarkeit | Vollständig abgedeckt: Audit Log plus Deployments in Git: Umgebungen und Deployments liegen als Konfiguration im Git-Verlauf | Nicht angeboten: Serverzustände, die niemand rekonstruieren kann, wenn die Person im Urlaub ist |
| Server und Betrieb | Vollständig abgedeckt: Eigener Server per SSH oder Managed Server, mit Docker, Reverse-Proxy, SSL, Firewall und Backups | Teilweise abgedeckt: Pro Kunde eine gewachsene Maschine mit eigener Geschichte |
| Mobile Releases | Vollständig abgedeckt: Flutter, Expo und native Projekte bis in App Store, Play Store und Microsoft Store | Nicht angeboten: Signaturen, Zertifikate und Store-Formulare in Handarbeit |
| Onboarding im Team | Vollständig abgedeckt: Ubuntu-Workspaces mit VS Code, JetBrains, RDP oder VNC. iOS-Builds auf macOS-Geräten der Pipeline | Nicht angeboten: Ein bis zwei Tage Einrichtung pro Rechner und Projekt |
| Übergabe an den Kunden | Vollständig abgedeckt: Repository, Pipeline-Konfiguration und Server-Setup sind dokumentiert und übertragbar | Nicht angeboten: Wissen steckt in Köpfen und lokalen Skripten |
| Kalkulierbarkeit | Vollständig abgedeckt: Plattform-Grundpreis plus Add-ons für Nutzer, Workspaces und CI-Minuten | Teilweise abgedeckt: Aufwände für Setup und Betrieb schwanken pro Projekt |
Grün bedeutet abgedeckt, gelb teilweise, grau nicht vorhanden. Die rechte Spalte beschreibt keinen Wettbewerber, sondern den üblichen Zustand ohne durchgängige Plattform.
Stand: 10. August 2026. Die Gegenüberstellung beschreibt typische Abläufe und kann je nach Projekt abweichen. Logos sind Marken der jeweiligen Rechteinhaber und dienen nur der Zuordnung.
Was Agenturen konkret gewinnen
Sechs Punkte, die im Tagesgeschäft mit mehreren Kunden den Unterschied machen.
Whitelabel aus einer Codebasis
Mehrere Marken entstehen als Varianten desselben Projekts. Build, Deployment und Veröffentlichung laufen für jede Marke über dieselbe Pipeline.
Rechte pro Kunde getrennt
Organisationen, Rollen und Zugriffsrechte legen fest, wer welches Projekt sieht. Zugangsdaten liegen zentral verwaltet statt in Notizen.
Nachvollziehbare Änderungen
Das Audit Log hält fest, wer wann was geändert hat. In Reviews und bei Rückfragen des Kunden musst du nicht rekonstruieren.
Übergabe ohne Wissenslücken
Umgebungen und Deployments liegen als Konfiguration im Repository. Am Projektende übergibst du ein System, das sich lesen lässt.
Releases bis in die Stores
Mobile Apps werden gebaut, signiert und mit Metadaten und Screenshots in App Store, Play Store und Microsoft Store veröffentlicht.
Gemeinsame Codebasis
Live Fahrplan
Ein Flutter Projekt. Daraus entstehen viele eigenständige Apps.
-
KVB Live Fahrplan iOS Android -
MVG Live Fahrplan iOS Android -
RMV Live Fahrplan iOS Android -
HVV Live Fahrplan iOS Android -
VVS Live Fahrplan iOS Android
So führst du die Plattform in der Agentur ein
Ein Kundenprojekt als Pilot reicht, um den Ablauf zu bewerten.
-
Organisation anlegen
Lege eine Organisation für die Agentur an und trage dein Team mit Rollen ein. Zugriffsrechte lassen sich später pro Projekt verfeinern.
-
Pilotprojekt aufsetzen
Wähle ein laufendes Kundenprojekt mit überschaubarem Umfang, lege es im Assistenten an und verbinde einen eigenen oder einen Managed Server.
-
Muster festhalten
Passe die Pipeline-Konfiguration im Repository an deine Standards an. Was sich bewährt, wird zur Vorlage für das nächste Projekt.
-
Weitere Kunden übernehmen
Neue Projekte starten mit demselben Setup. Bestehende Projekte ziehst du nach und nach um, sobald ein Relaunch oder ein größeres Release ansteht.
Häufige Fragen
Können wir Kundenprojekte sauber voneinander trennen?
Ja. Projekte liegen in Organisationen, und Rollen sowie Zugriffsrechte bestimmen, wer welches Projekt sehen und bearbeiten darf. Zugangsdaten und Secrets werden zentral verwaltet, statt weitergegeben zu werden, und das Audit Log zeigt, welche Änderung von wem kam.
Was passiert am Ende eines Projekts, wenn der Kunde übernehmen will?
Der Code gehört dem Kunden, mit vollständiger Code-Ownership. Repositories, die GitLab-CI-Konfiguration und die Deployment-Beschreibung der Umgebungen sind lesbare Dateien, die sich übertragen lassen. Der Wechsel ist eine Übergabe, kein Neuaufbau.
Lohnt sich das auch für kleinere Aufträge?
Bei kleinen Budgets fällt der Setup-Aufwand am stärksten ins Gewicht, deshalb ist der Effekt dort oft am deutlichsten. Ein Projekt, das sonst Tage an Grundarbeit erfordert, entsteht mit dem Assistenten in einem Bruchteil der Zeit. Je mehr Projekte parallel laufen, desto klarer wird der Unterschied.
Wie funktionieren Whitelabel-Projekte in der Praxis?
Du definierst die Varianten im Projekt: Branding, Domain und Store-Eintrag pro Marke. Die Plattform baut und veröffentlicht jede Variante aus derselben Codebasis, sodass ein Bugfix jede Marke erreicht, ohne separate Repositories abzugleichen.
Müssen wir unsere Server aufgeben?
Nein. Du kannst bestehende Server per SSH anbinden, und die Plattform richtet Docker, Datenbanken, Reverse-Proxy, SSL, Firewall und Backups darauf ein. Alternativ buchst du einen Managed Server. Viele Agenturen mischen beides, je nach Kunde.
Prüfe es an einem Kundenprojekt
Registriere dich kostenlos, lege ein Projekt an und vergleiche den Aufwand mit deinem bisherigen Setup.
Kostenlos starten. Keine Kreditkarte nötig.