Use-Case

Jedes Kundenprojekt als eigenes Projekt, nicht als Theme-Kopie

Agenturen erben WordPress-Multisite, geteilte Hosting-Accounts und eine Pipeline, die niemand anfassen will. Die Application Platform legt pro Mandant Repository, CI/CD und Server-Grundsetup an. Das Team arbeitet in Workspaces, der Kunde sieht nur sein Projekt.

Ein Projekt pro Kunde: Repo, Pipeline, Secrets, Deployments getrennt
Workspaces fürs interne Team, ohne lokale Toolchains zu vereinheitlichen
Store-Releases und Whitelabel, wenn aus der Website eine App wird

Kostenlos registrieren Für Agenturen

Kostenlos starten. Keine Kreditkarte nötig.

Isolation Kein gemeinsames wp-content, kein geteiltes Plugin-Update für alle Mandanten.

Wiederholbar Das nächste Mandantenprojekt startet mit derselben Kette, nicht mit einer Kopie von letzter Woche.

Zugänge Rechte pro Person und Projekt, Audit statt weitergeleiteter .htpasswd.

Anna Weber
Organisation, Mitglieder & Abrechnung

Administrator
Max Schneider
Code, Git & Deployments

Developer
Tom Richter
QA auf Dev & Staging

Tester
Paul Klein
Kunden-App & Feedback

Kunde

Zugänge pro Person und Mandant, nicht ein Sammel-Login.

Kurz gesagt

Die Plattform ersetzt nicht die Agenturarbeit am Produkt. Sie ersetzt das wiederholte Aufsetzen der Umgebung.

Pro Mandant ein Projekt, nicht eine Multisite und nicht ein Unterordner.
Dieselbe Kette für Web, Backend und später die App.
Interne Arbeit in Cloud-Workspaces, Kundenzugang getrennt.
WordPress-Multisite bleibt ein CMS-Modell – hier ist es Software pro Kunde.

Mandanten in der Plattform oder als WordPress-Multisite

Multisite spart Installationen. Es koppelt Updates, Plugins und Ausfälle. Die Plattform trennt bewusst.

Neues Kundenprojekt starten

Mit der Application Platform: Projekt anlegen, Stack wählen, Pipeline und Repo entstehen

WordPress-Multisite / geteiltes Hosting: Site in der Multisite anlegen oder Installation klonen

Updates und Plugins

Mit der Application Platform: Abhängigkeiten im jeweiligen Repo, Pipeline prüft den Stand

WordPress-Multisite / geteiltes Hosting: Ein Plugin-Update trifft alle Sites oder bleibt liegen

Ausfall eines Mandanten

Mit der Application Platform: Betrifft sein Projekt und seinen Server, nicht die Nachbarn

WordPress-Multisite / geteiltes Hosting: Plugin- oder PHP-Fehler kann die ganze Multisite ziehen

Kunde übergeben / rauslösen

Mit der Application Platform: Repository und Server gehören zum Projekt, Übergabe ist ein Rechtewechsel

WordPress-Multisite / geteiltes Hosting: Export aus der Multisite, oft mit Restabhängigkeiten

Team intern entwickeln

Mit der Application Platform: Cloud-Workspaces, gleiche Tools, ohne jedem Mac die Toolchain zu erklären

WordPress-Multisite / geteiltes Hosting: Lokales MAMP/Docker, abweichende PHP-Versionen

App zum Kundenprojekt

Mit der Application Platform: Frontend im selben Projekt, Store-Metadaten und Signing mit

WordPress-Multisite / geteiltes Hosting: Separates App-Projekt, oft anderer Dienstleister

Multisite bleibt effizient, wenn wirklich nur Content-Sites mit identischem Stack existieren. Sobald Logik, Apps oder getrennte Verträge dazukommen, wird Trennung billiger.

Stand: 4. September 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 die Agentur nicht mehr pro Mandant neu erfindet

Die handwerkliche Arbeit am Produkt bleibt. Das Gerüst nicht.

Projektstart in Minuten

Repo, CI, Homepage- oder App-Stack und Server-Grundsetup entstehen mit dem Assistenten.

Workspaces fürs Team

Ubuntu-Workspaces zum Entwickeln, statt jedem Laptop dieselben SDKs zu erklären.

Whitelabel, wenn Marken sich ähneln

Mehrere Marken aus einer Codebasis, jede mit Domain und Store-Eintrag – statt Fork pro Logo.

Verträge und EU

AVV und Betrieb in der EU, wenn der Kunde im Einkauf nachfasst.

acme / kunden-app

kunden-app
Flutter-App für iOS, Android und Web
backend
API und Server-Logik mit Docker-Setup
homepage
Marketing-Seite und öffentliche Inhalte
e2e-tests
End-to-End-Tests gegen Dev und Staging
gitops-configuration
Deployment-Konfiguration für Dev und Prod
local-configuration
Workspace-, IDE- und Agent-Konfiguration
gitlab-profile
Projekt-Dokumentation und README

Jedes Kundenprojekt hat sein Repository in der Organisation.

So läuft ein Mandant auf der Plattform

Der Ablauf ist für das nächste Projekt derselbe. Genau das ist der Punkt.

Organisation und Zugänge

Agentur-Organisation, Team einladen, Rollen. Der Kunde bekommt später nur sein Projekt, nicht die Nachbarn.
Projekt anlegen

Stack wählen. Bestehendes Git-Repo importieren oder neu erzeugen. Server verbinden oder Managed Server buchen.
Liefern

Push löst Pipeline aus. Releases sind nachvollziehbar. WordPress-Altlast parallel lassen, bis abgenommen ist.
Übergeben oder weiterbetreiben

Weiterbetrieb durch die Agentur oder Rechte an den Kunden. Das Repository bleibt das Übergabeobjekt, nicht ein Hosting-Login.

Häufige Fragen

Kann der Kunde das Projekt später selbst übernehmen?

Ja. Repository, Pipeline und Server gehören zum Projekt. Die Übergabe ist ein Mitglieder- und Rechtewechsel, kein Export-Ritual aus einer Multisite.

Müssen alle Kunden auf denselben Server?

Nein. Pro Projekt eigener Server oder ein Managed Server. Geteilte Maschinen sind möglich, wenn ihr das bewusst so wollt – nicht weil die Plattform es erzwingt.

Ersetzt das euer internes Ticketsystem?

Nein. Es ersetzt das Aufsetzen von Repo, CI und Hosting. Jira, Asana oder Notion bleiben eure Planung.

Was ist mit bestehenden WordPress-Mandanten?

Die Migrationsseite gilt pro Mandant. Nicht alle gleichzeitig umziehen. Erst die Projekte, bei denen Plugin-Logik oder eine App ansteht.

Nächsten Mandanten als Projekt anlegen

Registriere die Agentur, lade das Team ein und starte das erste Kundenprojekt mit der Kette, die beim zweiten identisch sein soll.

Kostenlos registrieren Mit uns sprechen