White-label Salesforce development is engineering work on a Salesforce program that a consulting partner hands to another firm, which delivers it under the partner’s brand while the partner keeps the client, the solution design and the accountability. For a practice whose bench is fully committed, it’s an attractive idea – say yes to the next program without hiring for it, and keep both the margin and the relationship. It’s also an arrangement that can go wrong in ways a partner only finds out about once a provider’s code is sitting in a client’s production org.
I’ve written this for practice heads and delivery leads who are evaluating a white-label provider. I won’t repeat the general mechanics of working under someone else’s brand, since our guide to white-label subcontracting already covers them. Instead, I’ll concentrate on the decisions that are specific to Salesforce: which kinds of work make sense to hand over and which don’t, the quality controls that make outside code safe to deploy, the intellectual property and non-solicitation terms that matter, and how to start with an engagement small enough to learn from. At the end, there’s a vetting checklist, along with a candid account of where a firm like ours fits, and where it doesn’t.
Two very different things go by the same name
The phrase covers two kinds of provider, and mixing them up is the first mistake partners make. One is a general Salesforce development shop, which takes Apex, Lightning Web Components, flows and configuration off a backlog and hands them back as finished work inside the org. The other is a specialist in a particular layer – most commonly integration and data – which builds what connects the org to the ERP, the billing platform, the warehouse and the legacy systems, and doesn’t touch the org’s configuration at all.
The two solve different problems, and they carry different risks. A general development shop extends the partner’s own capacity for the work the partner already sells, which helps when the bottleneck is simply hours. A specialist brings skills the partner doesn’t have, which helps when the bottleneck is depth. The commercial risk is different too. A provider that can build everything inside the org can, by definition, deliver the whole implementation, and a partner should think hard about what that means for the account two years from now.
What is sensible to white-label, and what is not
Not every part of a Salesforce program benefits from being handed to another firm. A useful test is to ask how much of the work depends on the client relationship, and how well it can be specified, reviewed and accepted from the outside.
| Work | Sensible to white-label? | Why |
|---|---|---|
| Solution design, process workshops, roadmap and advisory | No | This is what the client hired you for, and it’s where the relationship lives. Outsource it, and you’ve outsourced the account. |
| Org architecture and data model decisions | Rarely | These shape everything else. A provider can advise, but the partner should own the decisions and be the one to defend them. |
| Declarative configuration and administration | Usually not | It sits close to the client’s day-to-day needs, and it’s usually the core of the partner’s own practice. |
| Apex and LWC feature development | Yes, with strong controls | It can be specified and reviewed, but outside code lands directly in the client’s org, so review and deployment discipline are essential. |
| Integration with ERP, billing and external systems | Yes, and often the best candidate | Technically it’s unlike the partner’s core work, it’s on the critical path, and it can be tested against clear acceptance criteria. |
| Middleware and MuleSoft work | Yes | It sits outside the org, and integration specialists do it well. |
| Data migration and cleansing | Yes | Bounded, measurable work, whose success can be proven with validation reports. |
| Post-go-live monitoring of integrations | Yes, under a managed agreement | It needs on-call coverage that most practices can’t justify staffing. |
The pattern is that client-facing judgment stays with the partner, and well-specified engineering can move. Integration and data migration sit at the most favorable end of that range. They’re the work least like what the partner’s consultants do every day, the work most often underestimated in proposals, and the work whose quality can be shown most objectively – because two systems either agree or they don’t.
Quality controls that make outside code safe
A sales call can’t tell you whether a provider’s engineers are any good, so the real question in white-label Salesforce development is whether the partner’s own controls would catch it if they weren’t. Four areas deserve attention before any work starts.
Code review on the partner’s terms
All work should arrive as pull requests into the partner’s repository, and someone on the partner’s side should review and approve each one before it’s merged. Static analysis – Salesforce Code Analyzer, say, or whatever tooling the partner already uses – should run on every change. Test classes should actually assert behavior, and shouldn’t exist merely to meet the platform’s minimum coverage requirement for deployment, which is a floor and says nothing about quality. For integration work, the review should go beyond the code to the design: how failures are retried, how duplicates are prevented, what gets logged, and how anyone will know when the interface has stopped working.
Org access that matches the work
A white-label provider should rarely need production access, and should never use shared logins. Wherever possible, its engineers should hold named accounts on the partner’s identity provider, with multi-factor authentication and permission sets scoped to the task in hand. Integrations should authenticate as a dedicated integration user that the partner owns. If a provider asks for System Administrator access to production in its first week, that request tells you more about its practices than its proposal does.
Sandboxes and environments
Development should happen in developer sandboxes or scratch orgs, with integration testing in a designated sandbox that’s connected to non-production instances of the external systems. User acceptance testing belongs in a partial copy or full sandbox that the provider can deploy to only through the pipeline. And agree in advance who may refresh which sandbox, because an unannounced refresh can wipe out weeks of integration test data and configuration.
DevOps and deployment
Source control should be the source of truth, and the provider should deploy only through the partner’s pipeline, whether that’s DevOps Center, a third-party release tool or scripted deployments from the repository. Changes made directly in an org, outside version control, are the most common way for outside work to become untraceable. Middleware and external services will have their own deployment path, and the release plan should sequence the two so an interface is never switched on before the metadata it depends on has arrived.
IP, non-solicitation and the contract
The general contract stack – an NDA, an MSA and subcontract agreement on the partner’s paper, and a statement of work for each engagement – applies here just as it does to any white-label arrangement. A few points deserve particular attention on Salesforce work.
Intellectual property in the deliverables should follow the partner’s agreement with its client, which normally means the partner or the client owns them. Any pre-existing code the provider brings along (a logging framework, a trigger handler pattern or an integration library, for instance) should be identified at the outset and licensed, so that nothing left behind in the org or the middleware creates a dependency. Be wary of providers that deliver their utilities as managed packages whose source the client can’t see, because that’s a dependency by design.
Non-solicitation should run in both directions and cover clients as well as staff, with a clear scope and a reasonable duration. On Salesforce work, it should also deal with the provider’s own platform ambitions. A firm that runs a Salesforce implementation practice can sign a non-solicit in perfectly good faith and still find itself, a year later, being asked by your client to quote for the next phase. The protection that holds up best is structural – a provider whose business model gives it no reason to want your account in the first place.
This is practical guidance, not legal advice. Have your own counsel review the agreements.
Start with one piece of work
The cheapest way to evaluate a white-label provider is to give it something real, bounded and observable before you trust it with a program. A single integration with defined acceptance criteria, a trial run of a data migration with a validation report, or a short review of an existing integration estate will all do the job. The quality of the output matters, of course, but what the partner is mostly testing is the behavior around it: whether status arrives in a form the delivery lead can pass upward, whether risks are raised early and plainly, whether the provider works inside the partner’s tools without friction, and whether anything ever reaches the client that shouldn’t have.
A first engagement should also be scoped so it can be accepted objectively. “Migrate the legacy accounts” invites an argument at the end. “Every active account in the source is loaded once, duplicates are merged under agreed survivorship rules, and a validation report reconciles record counts and key balances by region” leaves nothing to argue about. Our article on scoping integration work in a statement of work explains how to write criteria like that.
Vetting checklist for a white-label Salesforce provider
- Does the provider run a Salesforce implementation or advisory practice that could compete with yours?
- Which kind of provider is it – a general development shop, or a specialist in a layer you lack?
- Will all its work arrive as pull requests into your repository, approved by your reviewer before merge?
- Does it run static analysis, and do its test classes assert real behavior, beyond just chasing coverage?
- Will it work without production access, using named accounts and scoped permission sets?
- Will it deploy only through your pipeline, with no direct changes in any org?
- How does it design integrations for failure – retries, idempotency, dead-letter handling, alerting and reconciliation?
- Can it show depth in the systems on the far side of the org, including ERP, billing and legacy platforms?
- Will it sign your paper, with mutual non-solicitation, and with IP that follows your client agreement?
- Will it identify and license any pre-existing code, and keep closed-source dependencies out of the org?
- What does the handover include, and could your team (or the client’s) run the work without it?
- Will it start with a single, fixed-scope piece of work?
Related reading
- White-label subcontracting for integration work
- Rescuing an ERP or Salesforce project
- NetSuite Salesforce integration: keeping CRM and ERP in agreement
- How Salesforce partners use integration subcontractors
How we approach it at eProxim
To be honest about where we fit: eProxim is an integration engineering firm, and we aren’t a general Salesforce development shop. I’d much prefer to say that plainly than take on work we aren’t built for. We don’t run a Salesforce implementation practice, we don’t do org configuration, declarative build or administration, and we don’t bid against partners. What we take on for Salesforce partners is everything outside the org boundary – ERP, finance and billing integration, external APIs the org consumes or exposes, middleware and MuleSoft work, event streaming, and data migration with validation reporting. We’ve been engineering that layer underneath other firms’ client relationships since 1997, we sign a mutual non-solicit on Salesforce work, and we work on your paper, under your domain, in your tools and through your process. If what you need is feature development inside the org, a general Salesforce development provider is the better fit, and the checklist above applies to it every bit as much.
Our services for Salesforce partners show where the line sits, the white-label delivery page sets out the operating rules, and the partner FAQ answers the contract and IP questions partners tend to ask first. Partners usually start with one integration, or with a single deep dive. If you have integration work on a Salesforce program that you’d prefer not to staff yourself, start a partner conversation.