Use case

Each client as their own project, not a copied theme

Agencies inherit WordPress multisite, shared hosting accounts and a pipeline nobody wants to touch. The Application Platform creates repository, CI/CD and server bootstrap per client. The team works in workspaces; the client only sees their project.

  • One project per client: repo, pipeline, secrets, deployments separated
  • Workspaces for the internal team, without unifying every laptop toolchain
  • Store releases and whitelabel when the site becomes an app
Create a free account For agencies

Start for free. No credit card required.

Isolation No shared wp-content, no plugin update that hits every tenant.
Repeatable The next client starts with the same chain, not last week's copy.
Access Rights per person and project, audit instead of a forwarded .htpasswd.
  • Anna Weber

    Organization, members & billing

    Administrator
  • Max Schneider

    Code, Git & deployments

    Developer
  • Tom Richter

    QA on dev & staging

    Tester
  • Paul Klein

    Customer app & feedback

    Customer
Access per person and client, not a shared login.

In short

The platform does not replace agency product work. It replaces repeating environment setup.

  • One project per client, not a multisite and not a subdirectory.
  • The same chain for web, backend and later the app.
  • Internal work in cloud workspaces, client access kept separate.
  • WordPress multisite stays a CMS model – here it is software per client.

Tenants on the platform or as WordPress multisite

Multisite saves installations. It also couples updates, plugins and outages. The platform separates on purpose.

Start a new client project

With the Application Platform: Create a project, pick a stack, pipeline and repo appear

WordPress multisite / shared hosting: Add a site to the multisite or clone an install

Updates and plugins

With the Application Platform: Dependencies in that repo, the pipeline checks the revision

WordPress multisite / shared hosting: One plugin update hits every site or sits untouched

One client going down

With the Application Platform: Hits that project and its server, not the neighbours

WordPress multisite / shared hosting: A plugin or PHP fault can take the whole multisite

Hand over / extract a client

With the Application Platform: Repository and server belong to the project; handover is a rights change

WordPress multisite / shared hosting: Export from the multisite, often with leftover coupling

Internal development

With the Application Platform: Cloud workspaces, same tools, without explaining SDKs on every Mac

WordPress multisite / shared hosting: Local MAMP/Docker, drifting PHP versions

App for the client project

With the Application Platform: Frontend in the same project, store metadata and signing included

WordPress multisite / shared hosting: A separate app project, often another vendor

Multisite stays efficient when you truly only run content sites on an identical stack. Once logic, apps or separate contracts appear, isolation is cheaper.

As of 4 September 2026. This comparison describes typical workflows and can differ from project to project.

What the agency stops reinventing per client

Craft on the product stays. The scaffolding does not.

Project start in minutes

Repo, CI, homepage or app stack and server bootstrap come with the wizard.

Workspaces for the team

Ubuntu workspaces to develop, instead of teaching every laptop the same SDKs.

Whitelabel when brands are similar

Several brands from one codebase, each with domain and store listing – not a fork per logo.

Contracts and EU

DPA and EU operations when procurement follows up.

acme / customer-app

  • customer-app

    Flutter app for iOS, Android, and web

  • backend

    API and server logic with Docker setup

  • homepage

    Marketing site and public content

  • e2e-tests

    End-to-end tests against dev and staging

  • gitops-configuration

    Deployment configuration for dev and prod

  • local-configuration

    Workspace, IDE, and agent configuration

  • gitlab-profile

    Project documentation and README

Each client project has its repository in the organisation.

How a client runs on the platform

The sequence is the same for the next project. That is the point.

  1. Organisation and access

    Agency organisation, invite the team, roles. The client later gets only their project, not the neighbours.

  2. Create the project

    Pick a stack. Import an existing git repo or create a new one. Connect a server or book a managed server.

  3. Deliver

    A push runs the pipeline. Releases are traceable. Leave the WordPress leftover in parallel until acceptance.

  4. Hand over or keep operating

    The agency keeps operating or rights move to the client. The repository is the handover object, not a hosting login.

Frequently asked questions

Can the client take the project over later?

Yes. Repository, pipeline and server belong to the project. Handover is a membership and rights change, not an export ritual from a multisite.

Do all clients have to share a server?

No. Each project can have its own or a managed server. Shared machines are possible if you choose that – not because the platform forces it.

Does this replace our ticket system?

No. It replaces setting up repo, CI and hosting. Jira, Asana or Notion stay your planning.

What about existing WordPress tenants?

The migration page applies per client. Do not move everyone at once. Start with the projects where plugin logic or an app is next.

For agencies On-ramp and working style for agency teams. Whitelabel apps Several brands from one codebase. Migrate from WordPress One tenant at a time, not the whole multisite. Cloud development environments Workspaces for the internal team.

Start the next client as a project

Register the agency, invite the team and start the first client project with the chain you want identical on the second.

Register for free Talk to us

Start for free. No credit card required.