GuidesAgencies

White-label development for design agencies: how it works and what to ask

Many design agencies sell websites and products but do not keep developers on staff. White-label development fills that gap: an outside team builds the work, and the agency delivers it under its own name. It works well when both sides agree on scope, ownership and access before the first line of code. This guide explains how these partnerships run, what to put in writing and which questions to ask before you sign.

By Endline Studio · Updated November 4, 2026

What white-label development means

In a white-label setup, the development partner works behind the agency. The client hires the agency, sees the agency's name on the proposal and invoice, and usually never talks to the partner directly. The partner builds what the agency designed and hands it back for delivery.

This is different from two other common arrangements:

Referral. The agency introduces the client to a developer, and the developer contracts with the client directly. The agency loses control of the relationship.
Co-branded partnership. Both companies appear in front of the client. This can work for large projects, but the client knows there are two teams and may compare them.

White-label suits agencies that want to own the client relationship, keep a consistent brand, and add development capacity without hiring. Typical scopes are front-end builds from Figma, Webflow or Framer sites that need custom code, Next.js sites and web apps, Shopify themes, and integrations with CMSs, CRMs or payment tools.

How a white-label project runs

Most projects follow the same shape:

Brief and estimate. The agency shares the design or a scope document. The partner asks questions and returns an estimate and a timeline. Good partners flag risks here, such as features the chosen platform cannot do without custom code.
Agreement. Scope, price, timeline, ownership, confidentiality and payment terms are signed. More on this below.
Handoff and access. The agency shares the final design files and invites the partner into the accounts the build needs.
Build with check-ins. The partner shares progress on a staging URL at agreed points, not only at the end.
QA and revisions. The agency reviews against the design, logs issues in one place and separates bugs from new requests.
Launch and handover. The partner supports the launch, documents anything non-obvious and removes or reduces its access.

The agency stays the single point of contact for the client throughout. If the client asks a technical question, the agency relays it or brings the partner into a call under the agency's name, if both sides have agreed to that.

Engagement models

There are three common ways to structure the work:

Per project. A fixed scope and a fixed or estimated price. Best for one-off sites and builds with a clear design. Changes go through a change request.
Retainer. A set amount of capacity each month. Best for agencies with a steady flow of smaller tasks, maintenance or client updates. Ask what happens to unused hours and how fast requests get picked up.
Embedded. A developer works as part of your team, joins your tools and standups, and may use an agency email address. Best for long projects or when the client expects a named team.

Many agencies start with one project to test the fit, then move to a retainer once they trust the quality and communication.

Who owns the work

This is the most important clause, and the one agencies skip most often. Your client expects to own what they paid for. That only works if you own it first.

In the United States, a work made by an independent contractor is not automatically owned by the company that paid for it. The U.S. Copyright Office's Circular 30 explains that a commissioned work counts as a "work made for hire" only if it falls into one of nine specific categories listed in the Copyright Act and the parties sign a written agreement that expressly says so. If any requirement is missing, it is not a work made for hire.

Website code does not fit cleanly into those categories. That is why contracts with outside developers usually include a written assignment of copyright from the partner to the agency, not only a "work for hire" line. Laws differ by country, so have a lawyer review the template once. This guide is not legal advice.

The ownership section should also cover:

When ownership transfers. Often on final payment. Make sure that matches what you promise the client.
Pre-existing code. Partners reuse their own starter kits and utilities. The usual approach is that the partner keeps those and grants you a license to use them in the project.
Third-party pieces. Open source packages, fonts, plugins and paid apps each carry their own license. Ask for a list.
Portfolio rights. In a white-label deal, the partner should not show the work publicly or name the client unless you allow it in writing.

Accounts and access

A simple rule saves a lot of trouble: the client or the agency owns every account, and the partner is invited in. Avoid projects that live in the partner's own workspace unless you have a clear transfer plan.

Webflow. Webflow has an Agency or Freelancer guest role. The host Workspace (your client or your agency) invites a guest team, which sees only the sites it is given access to and cannot reach billing, plans or team settings. The guest needs a Freelancer or Agency Workspace plan. Webflow also notes that if a site lives in a freelancer's or agency's Workspace, that Workspace owns it, and the client does not automatically get transfer rights unless that was agreed. Sites can be transferred between Workspaces, with conditions that depend on the plans involved.
Framer. A project owner or workspace admin can transfer a project from File, Transfer Project. The site stays online and connected domains keep working, but the current site subscription is canceled when the transfer is accepted, and the new owner picks and pays for a plan. Plan this before launch day.
GitHub. Keep the repository in your organization or the client's, and add the partner as an outside collaborator: someone who is not a member of the organization but has access to specific repositories. If the partner started the repo, it can be transferred. Issues, pull requests, wiki, stars and watchers move with it, and old links redirect to the new location.
Vercel. Projects can be moved from one team to another, so a partner can build in its own team and hand the project over. It is still simpler to create the project in the team that will own it.
Shopify. Partners request collaborator access, and the store owner approves it and picks which areas the collaborator can use. Owners can require a four-digit collaborator request code. Store ownership cannot be transferred to a collaborator, and collaborator access expires if it is not used for 90 days.

For everything else (DNS, analytics, forms, email tools, API keys), use the platform's invite system or a shared password manager. Never send credentials over plain email or chat.

Client data and privacy

If the build touches personal data, such as form submissions, customer records or member accounts, privacy rules apply to the partner too.

For clients with users in the EU, the GDPR treats a company that processes personal data on behalf of another as a processor. Article 28 says processing by a processor must be governed by a written contract, and a processor cannot bring in another processor without the controller's prior written authorisation. In practice, if your agency is a processor for the client and your partner works with that data, you need the client's authorisation and a data processing agreement with the partner that passes down the same obligations.

The easiest way to reduce risk is to limit access. Partners rarely need production customer data to build a site. Use test data and staging environments where you can.

Questions to ask a partner

Use these on the first call. Clear, specific answers are a good sign.

Fit. Which platforms do you build on most? Can you show work similar to ours, even if it is under NDA and shared privately?
Process. What do you need from us to give an estimate? How do you handle changes once the build starts?
Communication. Who is our day-to-day contact? What time zone are you in, and how much overlap do we get? How fast do you reply?
Discretion. Will you sign an NDA? Do you agree not to contact or solicit our clients directly? Will you remove your credits, comments and links from the code and the published site?
Client calls. Can you join a call under our name if we need you?
Quality. How do you test across browsers and devices? Do you check accessibility and performance before handing over?
Ownership. Will you assign copyright to us in writing? What pre-existing code or third-party licenses will the project include?
After launch. Is there a bug-fix window? What does ongoing maintenance look like, and how is it billed?
Capacity. How many projects do you run at once? What happens if your main developer is unavailable?

Red flags

An estimate with no questions asked about the design or scope.
Pushback on putting ownership or confidentiality in writing.
Insisting the project live in the partner's own accounts with no transfer plan.
No staging link until the end of the project.
Asking for full admin access when a narrower role would do.
Partner branding or "built by" links left in the delivered site.
Vague answers about who will actually do the work.

Checklist

Run through this before you start a white-label project:

Scope, deliverables and definition of done written down
Engagement model agreed: per project, retainer or embedded
Communication channel and who talks to the client agreed
No partner branding, credits or links on client work
NDA and non-solicitation terms signed
Written assignment of copyright from partner to agency
Third-party code, fonts and licenses listed
Client owns the Webflow or Framer workspace, repo, hosting and domain
Partner invited with the narrowest role that does the job
Data processing agreement in place if personal data is involved
QA process, target browsers and approver agreed
Handover: docs, credentials rotated, partner access removed

Sources

Platform facts come from each vendor's official documentation. Legal points come from the U.S. Copyright Office and the official GDPR text on EUR-Lex.