White-Label Subcontracting for Microsoft Partners

Looking for a White-Label Dynamics 365 Development Partner?

If you need to outsource Dynamics 365 development without building an in-house team, Solzet acts as your dedicated Dynamics 365 development subcontractor for Microsoft partners and systems integrators. As a white-label Dynamics 365 partner, we work invisibly under your brand - using your email, your project tools, and your documentation templates - while delivering senior-level work that upholds your quality standards. Whether you need a single consultant for a sprint or a full delivery team for a 12-month programme, our B2B engagement model gives you flexibility, legal certainty, and consistent quality with no recruitment risk.

How does white-label Dynamics 365 subcontracting work?

White-label means our consultants appear to your end client as members of your team. Practically, this means: (1) we use your company email addresses and communication channels, (2) all documentation, presentations, and deliverables carry your branding, (3) we join client meetings as "your" consultants, (4) our LinkedIn profiles are not shared with your client. The commercial relationship is between Solzet and your organization only - governed by a B2B contract, NDA, and SOW that defines scope, IP ownership, confidentiality, and payment terms. You bill your client at your rates; you pay us at our agreed rates. This model lets you take on more projects, cover skill gaps (especially PCF/TypeScript), and maintain margins without the risk and overhead of permanent hires.

The questions partners actually ask before they subcontract are operational rather than philosophical: who owns the client, whose paper the work sits on, whose name the client sees, when the solution becomes theirs, what stops a subcontractor walking off with the account, and how to try a supplier without committing a quarter. The sections below answer each one the way we set engagements up, and say what we recommend you agree in writing. Why partners subcontract in the first place, and the wider case for doing it, is covered in why Microsoft partners subcontract D365 work, and how to do it right. If you are a client rather than a partner and need senior people inside your own team, the same model read from the other end is Dynamics 365 staff augmentation and subcontracting.

Who holds the client relationship and signs the statement of work?

You do. The end client contracts with your organisation, signs your statement of work and pays your invoices, and you remain the accountable prime for delivery. Solzet signs a separate B2B agreement and SOW with you alone, so there is no contract, invoice or commercial conversation between Solzet and your client. That is the whole point of white label, and it is also what keeps accountability clean: when something needs escalating, it escalates to you, and you decide what the client hears.

What we recommend you write into the back-to-back SOW with us: the scope in the same work breakdown your client SOW uses, so acceptance on one maps onto acceptance on the other; the named roles and whether substitution needs your consent; the review and acceptance route for each deliverable; the confidentiality and data processing obligations your client contract passes down; and the notice period and handover shape if you scale down. Check your own client contract before you start, because some require the client to approve any subcontractor, and that approval is yours to obtain, not ours.

Whose names appear in the client tenant and on client calls?

Yours, in every place the client reads as a brand, and the individual consultant in every place that has to identify a real person. Our consultants join workshops, standups and client calls as members of your delivery team, under your email address and your Teams or other channels, and they do not list your clients on their public profiles. Access to the client environment runs on accounts you issue or arrange, typically an account on your own domain or a guest invitation the client or you controls, with only the security roles the work needs and whatever multi-factor authentication and conditional access policy applies. You can revoke it at any time.

Agree up front how consultants appear by name. Dataverse records the user on every created and modified record, in audit history and on solution imports, so the display name on the account is what the client will see for the life of the system. We recommend real individual names on your domain rather than shared or generic logins, because a shared account breaks the audit trail your client may rely on for compliance. There are also technical places a subcontractor name can leak if nobody checks: the publisher and prefix on a Dataverse solution, the namespace in a PCF control manifest, and commit author details in the repository. We build under the publisher, namespace and repository you specify, so none of those needs to carry our name, and it is worth checking all three at your first code review.

How do IP and solution ownership transfer at acceptance?

Intellectual property created in the engagement belongs to your organisation, or passes through you to your end client, as the SOW defines. The practical question is not who owns it in principle but where the work physically lives while it is being built and what is handed over at acceptance, because ownership that exists only on paper is still a dependency.

The structure we recommend: source code and unmanaged solution source live in your repository from the first commit, reviewed through your pull request process, so there is never a copy only we hold. Solutions are built under your publisher, or your client's if your contract says so. At acceptance of each deliverable you receive the managed solution ready for import, the source that produced it, and documentation in your format, and the SOW should state that assignment of rights takes effect on acceptance, or on payment if that is how your client contract runs, so the chain matches the one you have with your client. Any reusable component we bring in, such as a control from our PCF controls library, should be listed in the SOW with the licence terms it comes under, so nobody discovers a pre-existing component at handover.

What should the NDA and non-solicit terms cover?

Three separate things, and a partner should see all three in writing before sharing a client name. A mutual NDA, signed before any project detail is disclosed, covering the client identity as well as the technical and commercial information. A data processing agreement, because a subcontractor working in a client tenant will touch personal data, with terms we will match to whatever your client contract obliges you to pass down. And a non-solicitation clause that protects the relationship you own.

On non-solicitation, agree how long it runs after the engagement ends, whether it covers only approaches we make or also work your client offers us directly, and whether it applies to staff in both directions. Our position is simple: the commercial relationship exists only between your organisation and Solzet, and our incentive is that you win the next deal, because that is where the next engagement comes from. The blog post why Microsoft partners subcontract D365 work sets out the wider agreement structure, including quality control, if you are writing your first subcontracting template.

Which IP, restraint and payment terms should a prime partner agree with a white-label subcontractor?

Start by separating three things that the first lines of most subcontracting templates run together. The deliverable IP created for your specific client: the solution, configuration, plugins, flows and documentation built for that engagement. The subcontractor's pre-existing reusable components: controls, libraries, scripts and accelerators that existed before the engagement and are used across many clients. And general know-how: the skills, methods and experience a consultant carries from one project to the next. A prime can reasonably own the first, or pass it to the client. The second should be licensed to you and your client, not assigned, through a background IP carve-out. The third is never surrendered by anyone, because no contract can take it back out of a person's head, and a clause that tries to is usually either unenforceable or a signal the relationship will not last.

Getting this right protects the prime as much as the subcontractor. If a template assigns everything, including background IP, a serious subcontractor either refuses, prices in the loss of reusable assets, or quietly avoids using the components that would have made delivery faster and better tested. A clean carve-out with a broad licence gives you and your client everything you actually need: the right to use, modify, maintain and hand the solution to another supplier, indefinitely, with no dependency on us. The clause shape below is what we recommend and what we sign. It is a factual description of common commercial practice, not legal advice: have your own counsel review it against your client contract and the governing law you use, because assignment, restraint of trade and payment clauses are treated differently in different jurisdictions.

Where the work physically lives and how ownership passes at acceptance is covered in the section above on IP and solution ownership, and the wider agreement structure, including quality control, is in why Microsoft partners subcontract D365 work. The checklist here covers the clauses that most often go wrong, followed by the operational rules that keep a white-label arrangement workable day to day.

• Background IP carve-out: a schedule in the SOW listing each pre-existing component, with a clause that anything not listed and built within scope counts as deliverable IP. That removes the argument at handover.
• Licence, not assignment, for reusable components: perpetual, irrevocable, royalty-free and transferable to the end client, with the right to modify and to let another supplier maintain it. Ask for the source, not only the compiled output.
• Deliverable IP assignment: on acceptance of each deliverable, or on payment if your client contract runs that way, so the chain matches the one you have with your client.
• Non-solicitation, not a non-compete: a non-solicit protecting your client and your staff for a defined period after the engagement is reasonable and standard. A non-compete that bars the subcontractor from working for any Dynamics 365 customer, any partner, or a whole industry or country removes its market, is often unenforceable, and tells you the prime expects the relationship to be adversarial.
• Direct offers from your client: agree in writing what happens if your client approaches the subcontractor directly during or after the engagement. The usual shape is that it is declined or referred back to you for the non-solicit period.
• Payment terms that do not depend on the end client paying: invoices to the subcontractor fall due on agreed dates after acceptance, whatever happens in the commercial relationship between you and your client. Pay-when-paid or pay-if-paid wording moves the credit risk of your client onto a supplier who has no say in that relationship, and in some jurisdictions and sectors it is restricted by law.
• Disputes handled on their own track: a dispute with your client about scope or quality should not freeze payment for accepted work. Withhold only for the specific deliverable in dispute, under the acceptance route the SOW defines.
• Defined exit and handover: a notice period for scaling down, a list of handover artefacts (source in your repository, managed and unmanaged solutions, environment and configuration notes, open work items, a walkthrough session) and removal of all access on the last day, so either side can end the arrangement without the client noticing a gap.
• Liability and warranty in proportion: a warranty period for defects in accepted deliverables and a liability cap tied to the value of the SOW, rather than an uncapped pass-down of everything you accepted from your client.

Should you buy surge capacity or a named delivery pod?

Partners ask for one of two shapes, and they need different paperwork. Surge capacity adds senior people into a programme you already run: your lead owns the design, your backlog sets the work, and our consultants take stories or workstreams inside your sprint. A named delivery pod is a team we assemble for a defined scope, usually a senior consultant who owns the design conversation plus developers, which takes a workstream such as a set of PCF controls, a Power Automate estate or a Customer Engagement module end to end inside your governance. We assemble pods per engagement from a network of senior specialists rather than carrying a large idle bench, so we will tell you on the first call when a specific person is not free rather than substitute someone weaker.

Why start with a fixed-scope pilot before committing bench capacity?

Because a deliverable you can review tells you more than any reference call, and it costs both sides less than a quarter of dedicated capacity that turns out to be the wrong fit. For a first engagement we scope a defined piece of work as a fixed-price work package with written acceptance criteria and milestone invoicing: a small set of PCF controls, a migration slice, an automation pack, or one workstream from your backlog. You see how we work inside your repository, your review process and your client's environments, and we get a proper read on your estimates before anyone reserves people for months.

If the pilot goes well it converts to dedicated resource or time and materials without renegotiating the legal framework, because the B2B agreement, NDA, DPA and non-solicit are signed once and each later engagement is a new SOW under them. If it does not, you have a finished, owned deliverable and no bench commitment to unwind. The three commercial models are compared further down this page, and the staff augmentation page covers which steps of vendor vetting can honestly be compressed.

Which Dynamics 365 work can you subcontract to Solzet, and which not?

Dynamics 365 Customer Engagement and Power Platform only. That means Sales, Customer Service, Field Service and Customer Insights; Dataverse, model-driven and canvas Power Apps, Power Automate, Power Pages and Copilot Studio; plugins and custom APIs; integration and data migration around them; and custom PCF controls in TypeScript and React. We do not take Dynamics 365 Finance, Supply Chain Management or anything else on the Finance and Operations side, Business Central or Dynamics NAV, and we do not take ERP implementation work of any kind. If your programme needs those, subcontract them to a specialist in them rather than to us.

One addition partners use: when an end client cannot or will not adopt Microsoft licensing, we can build custom CRM on React, Node.js, PostgreSQL and .NET under the same white-label, NDA and IP terms, so you can still recommend the right solution rather than lose the deal.

What evidence is there that white-label subcontracting with Solzet works?

The published example is PCF controls development for a UK Microsoft partner. A UK Microsoft Solutions Partner had won a Dynamics 365 implementation for a healthcare organisation and had no in-house TypeScript and React capacity for the custom PCF controls it required. Two senior Solzet developers joined the partner's delivery team white label for three months, using the partner's email and Teams channels and committing to the partner's Azure DevOps repository through its pull request review. The controls were delivered as managed solutions with documentation for the partner's maintenance team, and the partner engaged Solzet again on later projects. The case study has the full detail, and it is the mechanics described on this page applied to a named-pod engagement.

What engagement models does Solzet offer for subcontracting?

We offer three models. Dedicated resource: one or more of our consultants work exclusively on your project(s) for a defined period, typically 3-12 months. You get continuity, deep context, and predictable capacity. Time and materials: our consultants contribute hours as needed, tracked and billed monthly. Best for ongoing support, bug fixes, and enhancement backlogs. Fixed-price deliverable: we scope a specific deliverable (a set of PCF controls, a Power Automate automation pack, a D365 module configuration) and deliver it for a fixed price. Best for well-defined work packages where you want cost certainty.

Why subcontract Dynamics 365 work to a team in Armenia?

Three reasons. First, quality without overhead: Solzet provides senior Dynamics 365 professionals with direct Western European time-zone overlap, native English communication, and full GDPR/DPA compliance - without the overhead of maintaining an in-house team. Second, timezone: GMT+4 gives 4-6 hours of daily overlap with Western Europe - enough for standups, sprint ceremonies, and client workshops. Third, talent: Armenia has a strong software engineering culture (ranked in the top 30 globally by HackerRank), a growing Microsoft technology community, and universities producing computer science graduates at scale. Every Solzet consultant brings 8+ years of hands-on Microsoft ecosystem experience in Dynamics 365 and Power Platform specifically.