White-labeling DesignSetGo for your agency clients

You build apps for client sites; your clients pay you; you maintain the apps. The tools that make this workflow ten apps for ten clients in a quarter (the GitHub Action, the Pro harness for faster generation, the deploy CLI) all earn their keep.

The piece that closes the loop is white-labeling. From the client’s perspective, they shouldn’t have to know about us. They should see your agency’s name on the plugins page when they’re poking around in wp-admin. They should see your name in the admin sidebar where the apps list lives. The plugin should feel like part of your offering, not like a third-party dependency they ended up with.

This post covers what white-label does in v1, what it deliberately doesn’t, and the rationale for both. The honest summary: the v1 surface is narrower than I’d like to imply, because we shipped the parts that mattered first and left the rest for v2. But the parts we shipped are the parts that matter most to most agencies.

What white-label changes in v1

White-label is an Agency-tier feature (the top paid tier). Enabling it lets the agency configure a single brand name in their Pro settings, and that brand name overrides the “DesignSetGo” string in two places end-clients see:

1. The apps-list admin eyebrow. The DesignSetGo Apps admin page (Apps → All apps) has a small “DesignSetGo” eyebrow above the page title. With white-label, that becomes your agency’s name. The client looking at the apps list sees your brand at the top.
2. The wp-admin plugins listing. The Plugins page in wp-admin shows each plugin with a name, author, plugin URI, and description. With white-label, the DSGo Apps (free) and DSGo Apps Pro plugin rows are rewritten to show your agency’s name, your URL, and your description. The plugin still works the same; the client just doesn’t see “DesignSetGo” in the row.

That’s the v1 surface. Two locations, both in wp-admin, both where the client is most likely to notice “what’s this plugin doing here?”

What white-label doesn’t change in v1

The honest list of things we left out:

• The install dialog’s frame. The permission buckets and the dialog chrome stay DSGo-branded. We considered re-branding this and decided not to: the install dialog is a trust signal, and we’d rather have site owners associate the dialog’s design with our security guarantees than let it be re-skinned per agency.
• Error pages and toasts. The error strings (“DSGo couldn’t load this app”) are not re-branded in v1. The error codes stay the same regardless of branding, so your support can still reference them; this just means the visible string still says “DSGo.”
• The plugin’s source-code attribution. GPL-licensed code stays GPL-licensed; the author attribution in the source files is unchanged. End-clients don’t see this unless they’re reading PHP.
• CLI output. When developers run npx designsetgo apps deploy, the CLI success messages still say “DesignSetGo.” This is a developer-facing surface, and we kept it un-rebranded because the agency’s developers are using the same CLI we maintain.
• The handful of admin notices that link to our docs. Where the plugin links to docs for “learn more,” the link still points at our docs. We can’t reasonably mirror our entire documentation per agency.

The pattern, in case it’s not obvious: branding moves on surfaces the end-client sees as part of using the plugin; branding stays on surfaces where the client is unlikely to look, or where we have a reason to keep the original attribution. The boundary is “what the client expects to be part of your service” vs “what the client expects to be part of the underlying infrastructure.”

If we shipped v2 white-label, the additions would be: error string overrides, admin notice link overrides, maybe a logo upload that surfaces on the apps admin page. None of those are blockers; they just weren’t in the v1 cut.

How to enable white-label

In the agency’s Pro account dashboard, go to White-label:

Brand name:    Your Agency Name

That’s the whole configuration in v1. One field, free-text, the agency’s brand name as it should appear on the plugins page and the apps admin eyebrow.

The field saves to a single option in WordPress (dsgo_apps_pro_brand_name). If it’s empty or whitespace, the default “DesignSetGo” string passes through unchanged; agencies don’t have to actively disable white-label, they just leave the field blank.

Multi-site agencies (one agency, multiple client sites) configure this per-site, not per-account. Each client site has its own Pro plugin install and its own brand-name option. This is intentional: an agency might want different branding for different clients (a client’s own agency-of-record vs the agency’s house brand), and per-site config supports that without per-client account complexity.

A note on per-site billing

White-label is a Pro Agency-tier feature, but it’s licensed per-site, not per-agency. Each client site running white-labeled apps counts as one Agency-tier site license. This matters because:

• The agency can run 20 clients and pay for 20 Agency licenses, or run 20 clients with mixed tiers (Personal for some, Agency for the ones that need white-label).
• The agency can offer different tiers of service to different clients (some get the harness, some get white-label, some get both).
• A client who buys out their site and takes it in-house keeps the white-label setting until the license expires; nothing breaks at handoff.

Pricing is on the pricing page. The short version: Free $0, Personal $99/site/yr, Plus $199, Agency $399, with white-label kicking in at the Agency tier.

What clients see

A client visiting their wp-admin sees:

• In the plugins list: “Your Agency Apps” by Your Agency at youragency.com (instead of “DesignSetGo Apps” by DesignSetGo at designsetgo.dev).
• On the apps admin page: “Your Agency” as the eyebrow above “Apps” or “All apps” (instead of “DesignSetGo”).

If they Google “Your Agency Apps,” they don’t find us; they find your agency. If they Google one of our error codes (which still appear in error toasts), they might find our docs. That’s expected. The error codes are documented in our public reference and that documentation is the ground truth for the runtime; we’d rather have your client find accurate troubleshooting than have your agency reimplement our docs.

The freemium etiquette question

A topic worth being explicit about: should an agency white-label a free plugin?

Our position: yes. The free tier of DSGo Apps is GPL’d, and white-labeling it is allowed under the GPL. We don’t enforce branding requirements on the free tier; we ask politely that you mention DesignSetGo Apps in your client documentation, but it’s not a license requirement.

The Pro tier of DSGo Apps is licensed differently, and the per-site licensing creates a clear commercial relationship between us and the agency, regardless of what the end-customer sees. White-labeling the Pro tier is the use case white-label was built for. The implicit deal is reasonable: you pay us per site, we make it easy for you to present the plugin as part of your service.

What this is not

A few things white-label deliberately doesn’t do:

• It doesn’t hide the existence of DesignSetGo Apps from a developer who looks under the hood. Source code, file paths, internal class names: all unchanged. A developer auditing the site sees that the plugin is DesignSetGo Apps with re-skinned UI. White-label is a UX layer, not a forensic-evasion layer.
• It doesn’t relicense the plugin. Agencies can’t sell our plugin under a closed license; they can only re-brand the user-facing surfaces.
• It doesn’t fork the codebase. Updates to our plugin still come from us; agencies don’t accumulate divergent forks.

The simplest framing: white-label is for “our agency runs DesignSetGo Apps on behalf of clients, and the clients should think of it as our agency’s product.” It’s not for “we want to fork the plugin and pretend we wrote it.”

The v2 wishlist

A few things we know we’ll want to ship next, when we get back to white-label:

• Logo upload. The apps admin page should show your agency’s logo, not just your name. We have the rendering surface for it; we just haven’t built the upload UI.
• Error string overrides. The structured error codes stay; the human-readable strings get per-agency overrides. This is the next likely item.
• Configurable support link. Right now, the admin links to our support; an agency might want it to link to their support inbox. Small change, high value for agencies.
• Per-client brand profiles. Today, each site has one brand. Agencies running multi-site networks might want per-network-site profiles.

None of these are roadmap commitments; they’re the obvious list of “things that come up in agency calls.” Order is roughly likely-to-ship.

Where to go next

• The pricing & business-model doc for the per-tier feature breakdown.
• The GitHub Action post for the agency deploy workflow.
• The harness post for the other Pro feature agencies care about.