Referral, White-Label, or Joint Delivery? Choosing a Software Partnership Model

TL;DR

• Separate branding, contracting and delivery management. A named technical partner can work under a lead supplier's contract; one invoice does not require an invisible developer.
• A referral pays for an introduction if compensation is agreed. White-label delivery adds a client-facing service to manage. Joint delivery needs explicit boundaries between both teams' contributions.
• Compare the return after your own project work, not just the developer's fee. Check when money comes in and when supplier payments fall due.
• Rehearse one scope change and one support incident before committing. Identify who explains the impact, who authorizes work and who answers the client.
• Record future introductions, client contact and exit arrangements. Neither branding nor a referral fee settles code ownership, reuse rights or continuing support.

The client needs software. What role are you selling?

For example, suppose your design agency is working with an equipment-repair business. The client asks for a portal where customers can submit repair requests and see progress from its existing service system. Your team can design the experience, but you do not intend to build or operate the application yourself.

You could introduce a software team, sell the complete project under your brand, or work alongside a named development partner. The portal requirement stays the same. Your commitment to the client changes.

This scenario and the financial illustration below are hypothetical. They are not Caemcore client results, prices or partnership terms. First check whether an existing product can cover the workflow; choosing a partner model does not justify a custom build.

Separate branding, contracts and delivery responsibility

Treat these as three decisions. Who appears to the client? Who contracts and invoices for each part? Who has authority to make delivery decisions? Put actual company names and roles against the answers.

The labels can overlap. FullyCoded's agency page describes working behind the scenes or being introduced as a named technical partner. That is a published example of flexible presentation, not evidence that either option automatically carries particular payment or ownership terms.

For this comparison, referral means an introduction followed by a direct software engagement; white-label delivery means an agency-led service presented under the agency's brand; named joint delivery means both teams contribute with their roles visible to the client. These descriptions organize the discussion. They are not standard contracts or a recommendation to form a legal joint venture.

The same portal project under three arrangements

Referral: make the introduction, then hand over the build

Choose a referral when you can recommend a team but do not intend to manage its work. With the client's permission, introduce the developer, explain the portal request and share the relevant context. The developer and client establish the software scope and their working relationship directly.

Your agency can still deliver the website or a separately agreed design phase. Define that boundary: an introduction does not require you to stop working with the client, but retained design work is not automatically project management for the software build.

Agree how you learn whether the introduction was accepted and whether any referral payment has become due. Do not assume that every introduction earns a fee, or that a fee covers future projects indefinitely. Record the qualifying event, calculation and payment timing before relying on it.

Tell the client who owns the next step. A good handover ends with a named contact and an agreed conversation, not the client wondering which of two teams is preparing the proposal.

White-label: sell the service you are prepared to manage

Choose white-label delivery when your agency intends to present a combined service and remain responsible for managing the client-facing commitment. In the portal example, you prepare the client proposal using a development scope the software partner has actually reviewed. You coordinate feedback and acceptance; the partner leads the agreed engineering work.

That requires more than replacing a logo on the developer's estimate. Check that the proposal you sell includes the same portal behaviour, dependencies and support boundary the developer has priced. When the client asks for something outside that scope, someone at your agency must handle the conversation before the team starts work.

Agree how the technical lead gets answers. The developer might join selected calls as your delivery partner, or work through a named agency lead. Keeping a brand consistent should not force an account manager to guess the answer to an integration question.

Use another arrangement when you only want to make an introduction. A managed offer also needs someone to organize feedback and acceptance; the developer's code does not cover that client-facing work.

Named joint delivery: retain your contribution without hiding the developer

Choose named joint delivery when both teams have substantive work to lead. For the portal, the agency could own research and interface design while the software team owns the application, integration and technical release. The client sees who is doing each part.

You can have separate agreements with the client, or a lead supplier can hold the main agreement and engage the other team. Agree this explicitly. Two visible brands do not require two invoices; two invoices do not establish who coordinates the overall release.

Name the person who keeps shared decisions moving. For example, a change to the repair-status model may affect both interface copy and application behaviour. Each team needs to assess its part before anyone gives the client a delivery date.

Joint delivery is a poor fit when it means only that everyone joins the same chat. The client should know whom to ask for a decision and who will collect the response from both teams.

Rehearse a scope change before the first proposal

Suppose the portal initially lets customers view repair progress. During a review, the client asks customers to be able to approve an additional repair charge. Keep this as a hypothetical change to test the relationship, not a request for an unpaid feature.

Under a referral, the developer handles the request with the client and involves your agency only where retained design work is affected. Under white-label delivery, your agency obtains the technical impact, agrees any change with the client and authorizes the supplier's work. Under named joint delivery, the coordination lead collects both teams' impacts and sends one consistent decision for approval.

In each case, distinguish discussion from authorization. The Association for Project Management's change-control guidance separates recording and evaluating a request from approving, rejecting or deferring it. Apply that distinction to the shared project: a developer explaining that something is possible has not agreed to include it at the existing price.

Record the affected work, dependencies, cost, date and approver. A request can be deferred or traded against other scope. Do not quietly make the decision by letting one team start while the other still thinks it is being discussed.

Check the return after your own work, then check cash timing

Compare compensation for the role you are actually performing. A referral payment compensates an agreed introduction. A white-label client fee also has to cover the agency's delivery work. In joint delivery, price the contribution each team makes, including any coordination assigned to one of them.

Hypothetical calculation, in USD. Assume the portal service is sold for $24,000 and the software partner charges $18,000. The $6,000 difference is 25% of the client price, or a 33.3% markup on the supplier fee. It is not yet the agency's profit.

Now assume the agency spends 50 hours coordinating delivery and acceptance, valued at an internal cost of $60 per hour. That is another $3,000. The remaining amount is $24,000 - $18,000 - $3,000 = $3,000, before sales effort, overhead, financing, tax, unpriced rework and any other costs. These numbers are invented for the calculation, not recommended rates or a complete profitability model. A separately scoped design fee is outside this illustration.

An additional 50 hours at the same assumed cost would consume that remainder. That is why the client-response role, revision process and support boundary belong in the decision before you set the selling price.

Then check when payments happen. If a supplier milestone becomes payable before your client payment arrives, your business has to fund the gap unless different terms have been agreed. A positive project calculation does not answer that timing question. The Australian government's contract-preparation guidance calls for explicit payment triggers, amounts and acceptance conditions. Use those questions to compare the two agreements, without importing Australian legal rules into another jurisdiction.

For a referral, specify whether the payment trigger is a signed engagement, collected revenue or another agreed event. For joint delivery, clarify whether either team funds the other's work. Do not assume a revenue split also explains who invoices, collects payment or bears an unpaid balance.

Write a one-page working agreement before the contracts

Use a short working outline to expose disagreements before detailed terms are drafted. It supplements the project scope and contracts; it does not replace legal advice on liability, intellectual property, tax or data obligations.

For the repair portal, a named joint-delivery outline could read as follows. It is a proposed example, not a Caemcore offer.

• Client-facing roles: the agency leads research and design; the software partner leads application delivery. Both attend reviews when their work is involved. The client appoints a business decision-maker.
• Contract and billing route: each team proposes its own defined scope to the client. Shared testing and launch coordination are allocated to named people and included in the corresponding fees. Any referral compensation is agreed separately.
• Approval route: the agency delivery lead gathers feedback into one record. Both teams assess changes affecting their work. The client approves commercial changes through the agreed contracting route before implementation begins.
• Shared acceptance: the agency checks the interface against the agreed design; the software lead supplies evidence for the application behaviour. The client accepts the complete request-to-status journey, including the handoff into its service system.
• Support route: the software partner receives portal incidents; the agency receives website and design requests. A named incident coordinator brings in the other team when the cause is unclear. Coverage and response commitments require separate agreement.
• Future work and exit: the teams record how new client requests are routed, what happens if one team leaves, and which records and access the receiving owner needs. No continuing fee or exclusivity is assumed from the original introduction.

Read the outline back as a client. Can you tell who receives a new requirement, who can approve it and where to report a problem? If not, change the arrangement before adding a partnership label to the proposal.

Keep branding separate from rights and data access

Do not infer code ownership from whose logo appears in the portal. Ask the agreements to cover project-specific code, pre-existing components, third-party dependencies and the client's ability to maintain or transfer the application. In a white-label chain, compare what your agency promises the client with the rights it receives from the developer.

For a jurisdiction-specific example, the UK Intellectual Property Office's commissioned-work guidance says the creator is normally the first copyright owner unless otherwise agreed in writing. Paying for commissioned work and obtaining ownership are not the same thing. Have the actual rights and transfer arrangements checked for the applicable law, rather than treating this UK example as a worldwide rule.

Data responsibilities also need their own review. Under the ICO's UK GDPR guidance, a controller determines the purposes and means of processing, while a processor acts on the controller's behalf. A project described as joint delivery does not by that description establish joint-controller status. Map the actual activities and permitted access instead.

For the portal, identify who may see customer records during development and support, whose permission is needed and how access ends. A white-label presentation is not a reason to omit a supplier from a required security or data-processing review.

Agree what happens when the client calls after launch

Try one final scenario: a customer cannot see an updated repair status, and nobody yet knows whether the problem is in the portal or the client's service system. Who acknowledges the report? Who starts investigating? Who updates the client while the cause is unresolved?

In a referral, give the client the developer's agreed support route. For white-label delivery, ensure your client-facing response is backed by the support you purchased, including how the technical team is reached. In joint delivery, name the incident coordinator rather than asking the client to diagnose which supplier to contact.

Separate these operational arrangements from deciding who ultimately pays for corrective work. Record the issue, investigate it through the agreed process and distinguish an implementation defect, a changed dependency and a new requirement. Do not make the first useful response depend on a customer resolving that classification.

Discuss the role before the next client introduction

Once the role is clear, our comparison of software development partners for design agencies can help you identify teams to approach. Evaluate the proposed arrangement for the actual project, not just the partner page.

Caemcore builds custom business systems and integrations. Bring the client's task and explain the role you want to retain. Our role is to help define and build the software, rather than supply developers for another team to manage. Branding, contracting, any referral compensation and support terms need project-specific agreement; this guide does not establish a standard partnership programme.

About Caemcore

Caemcore builds custom software for companies that outgrew off-the-shelf tools.

Internal systems, integrations, web and mobile apps, and products built from scratch. Small senior team, Warsaw-based, working with clients across the EU, US and UK.

You get a price range and a timeline before development starts, a working demo every Thursday, and a final invoice that matches the number quoted on day one.

Not sure what you need? A 30-minute call, free: what the task actually is, whether it needs building or an off-the-shelf tool covers it, a range and a timeline. You get that whether we work together or not.

FAQ

Can a project start as a referral and become joint delivery?

Yes, but agree the new role before taking it on. Record the work you will now perform, your authority, the fee and any effect on the existing referral arrangement. Tell the client who owns decisions from that point onward. Joining a few meetings should not silently turn an introduction into an open-ended project-management commitment.

Should the client know that a referral is compensated?

Our recommendation is to make that financial interest clear when recommending the supplier, especially when the client relies on you for an impartial assessment. Explain what you have actually checked and what the client still needs to assess. Confirm any applicable contractual, professional or legal disclosure requirements; a referral payment is not evidence of the developer's suitability.

Can both teams join a sales call before choosing the model?

Yes. Introduce their proposed roles and say which terms remain undecided. Use the call to understand the task and agree the next scoping step, not to make an unreviewed commitment on another team's behalf. Before sending a combined offer, settle who quotes, who approves it and who pays for any detailed investigation.

Should we ask a software partner for exclusivity?

Start with the concern you need to address, such as unsolicited approaches to a named client. Discuss the intended boundary, duration, existing relationships and treatment of new inbound requests. Have any restriction reviewed for the applicable law. A broad restriction is not a substitute for a clear working relationship or evidence that the partner can deliver.

What should happen if the client approaches the developer directly for more work?

Use the contact route agreed for future requests. The developer can acknowledge the message without making a new commercial commitment, then involve the appropriate agency contact where agreed. If the client wants a different relationship, resolve the remaining obligations and new scope openly. Do not assume either a permanent referral entitlement or permission to bypass the existing arrangement.

Sources

• FullyCoded, Development for agencies. Checked 14 September 2026.
• Association for Project Management, What is change control?. Checked 14 September 2026.
• Australian Government, Prepare a contract. Checked 14 September 2026.
• UK Intellectual Property Office, Ownership of copyright works. Checked 14 September 2026.
• Information Commissioner's Office, What are controllers and processors?. Checked 14 September 2026.
• Caemcore, Custom systems and integrations. Checked 14 September 2026.
• Caemcore, Systems review. Checked 14 September 2026.

The repair-portal scenario, model comparison, working outline and financial calculation are editorial tools using disclosed hypothetical assumptions. They are not market benchmarks, legal templates or Caemcore partnership terms. FullyCoded's page illustrates a provider's own description, not independent delivery testing. Legal references are identified by jurisdiction; the ICO page states that its guidance is under review. Caemcore's service details are first-party information.