Jedes Projekt startet gleich
Struktur, Konventionen und CI/CD-Pipeline kommen aus vorbereiteten Templates

So unterscheidet sich der Alltag.
| Aufgabe |
|
Ohne MainPath |
|---|---|---|
| Projekt-Setup | Vollständig abgedeckt: Repository, Struktur, CI/CD-Pipeline, Server-Anbindung, Domain | 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 | 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 | Nicht angeboten: Kopierte Repositories, die nach wenigen Monaten auseinanderlaufen |
| Zugriffsrechte pro Kunde | Vollständig abgedeckt: Organisationen, Rollen und Zugriffsrechte trennen Projekte | Teilweise abgedeckt: Zugänge liegen verteilt in Passwortlisten und persönlichen Accounts |
| Nachvollziehbarkeit | Vollständig abgedeckt: Audit Log plus Deployments in Git: Umgebungen | 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 | 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 | Nicht angeboten: Signaturen, Zertifikate und Store-Formulare in Handarbeit |
| Onboarding im Team | Vollständig abgedeckt: Ubuntu-Workspaces mit VS Code, JetBrains, RDP oder VNC. | Nicht angeboten: Ein bis zwei Tage Einrichtung pro Rechner und Projekt |
| Übergabe an den Kunden | Vollständig abgedeckt: Repository, Pipeline-Konfiguration | Nicht angeboten: Wissen steckt in Köpfen und lokalen Skripten |
| Kalkulierbarkeit | Vollständig abgedeckt: MainPath-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 ist abgedeckt, gelb teilweise, grau nicht vorgesehen.
Sechs Punkte, die im Tagesgeschäft mit mehreren Kunden den Unterschied machen.
Struktur, Konventionen und CI/CD-Pipeline kommen aus vorbereiteten Templates
Mehrere Marken entstehen als Varianten desselben Projekts.
Organisationen, Rollen und Zugriffsrechte legen fest, wer welches Projekt sieht.
Das Audit Log hält fest, wer wann was geändert hat.
Umgebungen und Deployments liegen als Konfiguration im Repository.
Mobile Apps werden gebaut, signiert
Ein Flutter Projekt. Daraus entstehen viele eigenständige Apps.
Ein Kundenprojekt als Pilot reicht, um den Ablauf zu bewerten.
Lege eine Organisation für die Agentur an und trage dein Team mit Rollen ein.
Wähle ein laufendes Kundenprojekt mit überschaubarem Umfang, lege es im Assistenten an
Passe die Pipeline-Konfiguration im Repository an deine Standards an.
Neue Projekte starten mit demselben Setup.
Ja. Projekte liegen in Organisationen, und Rollen sowie Zugriffsrechte bestimmen, wer welches Projekt sehen und bearbeiten darf.
Der Code gehört dem Kunden, mit vollständiger Code-Ownership.
Bei kleinen Budgets fällt der Setup-Aufwand am stärksten ins Gewicht, deshalb ist der Effekt dort oft am deutlichsten.
Du definierst die Varianten im Projekt: Branding, Domain und Store-Eintrag pro Marke.
Nein. Du kannst bestehende Server per SSH anbinden
Erzähl uns, was ihr baut. Wir melden uns über das Kontaktformular.