Every project starts the same way
Structure, conventions and the CI/CD pipeline come from prepared templates

How the day-to-day compares.
| Task |
|
Without MainPath |
|---|---|---|
| Project setup | Fully covered: Repository, structure, CI/CD pipeline, server connection, domain | Not offered: Every client project opens with groundwork nobody likes to put on an invoice |
| Reusable foundation | Fully covered: Templates for Next.js, NestJS, Laravel, FastAPI, Flutter, Expo, native apps, Astro | Partly covered: An in-house boilerplate that someone has to maintain and that ages anyway |
| Multiple brands from one codebase | Fully covered: Whitelabel projects with their own branding, domains and store listings | Not offered: Cloned repositories that drift apart within months |
| Per-client access rights | Fully covered: Organisations, roles and access rights separate projects | Partly covered: Credentials scattered across password lists and personal accounts |
| Traceability | Fully covered: Audit log plus Deployments in Git: environments | Not offered: Server states nobody can reconstruct once the person who built them is away |
| Servers and operations | Fully covered: Your own server over SSH or a managed one, with Docker, reverse proxy, SSL, firewall | Partly covered: One hand-grown machine per client, each with its own history |
| Mobile releases | Fully covered: Flutter, Expo and native projects into the App Store, Play Store | Not offered: Signing, certificates and store forms done by hand |
| Onboarding developers | Fully covered: Ubuntu workspaces with VS Code, JetBrains, RDP or VNC. | Not offered: A day or two of machine setup per person and project |
| Handover to the client | Fully covered: Repository, pipeline configuration | Not offered: Knowledge sits in people’s heads and local scripts |
| Predictable cost | Fully covered: A MainPath base price plus add-ons for extra users, workspaces and CI minutes | Partly covered: Setup and operations effort varies from project to project |
Green is covered, amber is partial, grey is not included.
Six things that matter when you are serving several clients at once.
Structure, conventions and the CI/CD pipeline come from prepared templates
Brands are variants of the same project.
Organisations, roles and access rights decide who sees which project.
The audit log records who changed what and when.
Environments and deployments live as configuration in the repository
Mobile apps get built, signed and published to the App Store, Play Store
One Flutter project. Many independent apps come from it.
One client project as a pilot is enough to judge the workflow.
Create an organisation for the agency and add your team with roles.
Pick a live client project of manageable size, create it in the wizard
Adjust the pipeline configuration in the repository to match your standards.
New engagements start from the same setup.
Yes. Projects sit inside organisations, and roles and access rights decide who can see and edit each one.
The code belongs to the client, with full code ownership.
Small budgets are where setup overhead hurts most, so the effect is often clearest there.
You define the variants in the project: branding, domain and store listing per brand.
No. You can attach existing servers over SSH
Tell us what you are building. We reply through the contact form.