How Agencies Can Subcontract Development: Brief and Acceptance
Development is easier to subcontract when the stage has an agreed outcome, named owners and a process for scope changes. The agency manages its commitments to the client; the development partner delivers the accepted scope. Both teams need to understand that boundary before work starts.
This process is useful for SEO agencies, design studios and integrators when a client needs development beyond their own team. Unclear requirements, scattered feedback and late access can complicate even a small handover.
Below is a handover package for a website or integration, a responsibility matrix and an acceptance process. These are project management recommendations; the parties agree commercial terms and obligations for their specific engagement.
Choose a working model before estimating the project
First, decide who sells the work, who manages client communications, and who accepts the outcome. The words “partnership” and “outsourcing” can mean different relationships.
| Model | What does the agency convey? | What needs to be agreed upon |
|---|---|---|
| Artist's recommendation | Contact and task context | Fixation of acquaintance, further communication and reward |
| White label | Development under your own brand | Introducing the team, communication channels, coordinating responses to the client |
| Subcontract per stage | Limited results within the project | Input materials, dependencies and stage acceptance |
| Strengthening the team | A set of tasks or downloading a specialist | Who sets tasks, checks solutions and plans work |
NBM-IT presents these options on partnership page with agencies and web studios. The amount of remuneration, terms and other conditions should be checked there and recorded in the project agreements. A transfer process is required for each model chosen, but the depth of agency involvement will vary.
When white labeling, agree whether the developer can participate in technical meetings and on whose behalf. For stage subcontracting, determine who combines the results of different contractors. If one team makes the interface and another makes the API, someone should be responsible for testing the overall script.
Check that the request is ready for handover
Before making an assessment, the partner needs context: what problem is the client solving, what has already been agreed upon, what materials are ready and what is still unknown. It is useful to separate a confirmed requirement from a wish that is only being discussed.
For example, a client needs a service catalog with an enquiry. The design has been approved, the texts are still being prepared, CRM has been selected, but access rights have not been issued. Send exactly these statuses. If you write “everything is ready,” your partner will build a plan on assumptions that will be revealed after the start.
For a preliminary assessment, you can convey incomplete information by indicating limitations. Promising a launch date will require verified dependencies: content, accesses, coordination, external systems. The date becomes reasonable when the team understands what it needs to get and from whom.
If the request came from cold communication, first clarify the task and authority of the interlocutor. Material about outreach and attracting requests refers to this previous stage. A qualified task with a clear next action should be transferred to production.
The handover package for developers
Gather materials in one place and provide a version of the agreed scope. Links to correspondence are useful as history, but current requirements should be accessible without reading all messages.
| Material | What should it contain | Who confirms |
|---|---|---|
| Brief | Business problem, users, main scenario and limitations | Agency and client representative |
| Stage volume | Pages, functions, exceptions and transfer result | Agency and development partner |
| Layouts | Approved screens, mobile options, element states | Design Officer |
| Content | Materials, readiness status, placement rules | Content owner |
| Integrations | Systems, fields, events, test scripts | Technical representatives of the parties |
| Access card | What systems are needed, what rights and how are they issued? | Infrastructure owner |
| Acceptance plan | Who checks, where notes are recorded and what is considered completed | Agency and contractor |
| Change rules | Who agrees on the impact on scope, timing and cost? | Authorized representatives |
For redesign, please attach the addresses of existing pages, conditions for transferring materials and limitations of the working site. To develop from pre-built layouts, check for form errors, empty states, long text, and mobile navigation. Missing states must either be prepared or entrusted to the contractor with separate approval.
In the integration project, please include example data and expected results. For example: accessing a specific form creates an object in the desired funnel with consistent fields. This scenario allows you to evaluate and accept the work. The wording “connect CRM like the client’s” will require additional examination.
Assign responsibility at project boundaries
Assign one person responsible for decisions on the agency and contractor sides. There can be many participants, but conflicting comments must be united by the owner of the approval.
| Decision or action | Agency | development partner | Client |
|---|---|---|---|
| Business requirements | Collects and clarifies | Checks feasibility | Confirms the task |
| Technical solution | Checks compliance with the promised result | Proposes and justifies | Acknowledges the limitations of its systems |
| Content and approval | Organizes the transfer | Places according to accepted volume | Provides or approves materials |
| Volume change | Collects the request and agrees on the terms | Evaluates impact | Makes a decision based on the result |
| Stage verification | Receives from the contractor | Demonstrates and corrects defects | Verifies agreed business scenarios |
| Publication | Coordinates dates and notifications | Performs technical operations as agreed | Issues permission and necessary accesses |
This table is an example distribution and not a required model. If the agency does the posting itself or the client accepts the stage directly, change the appropriate lines. Empty responsibility for an integration test or launch is more dangerous than differences in role titles.
Separately agree on external communications. Who answers a client's technical question, who reports a delay, and who approves a new task? The developer can explain the decision, but the new timeline promise must go through the project owner.
Estimate the stage and control its scope
Request a proposal with results, assumptions, exceptions and dependencies. Record which works are considered mandatory, which can be postponed, and which are assessed after the survey. To compare offers use table for checking estimates for website development.
Do not promise the client the final price of an unknown integration before accessing its documentation and settings. A survey can be distinguished: the partner checks the exchange interface, restrictions and test script, then clarifies the scope of the implementation. The result of the survey must also be a concrete document or demonstration.
For each new request, record:
- What changes relative to the agreed upon outcome.
- What parts of the work already done are affected.
- What impact is expected on the term and assessment.
- Who approves the change and when it is included in the plan.
Separate defect and feature enhancement based on stage criteria. If the agreed form does not convey data, this is a reason to correct the execution. If a new funnel or another scenario appears, first clarify the scope. It is better to resolve the dispute based on recorded behavior, and not on the wording “quick revision.”
Access, source code and deployment
Determine where the repository, test environment, domain, and production infrastructure are located. Each resource must have an owner who can continue the project after the executor changes. Use separate accounts and rights for tasks instead of transferring general administrative access.
For example, GitHub allows you to assign different roles to an organization's repository. Securing branches may require approval of changes and successful checkouts; Feature availability may vary by product and settings. Select rules for your project and determine who can release changes to production.
Pass connection secrets through an agreed secure channel, separately from the general brief. The documentation needs access assignments and a method for issuing them, not open passwords. After completing the stage, check which rights remain for support and which should be revoked.
The publishing plan includes a preliminary check, a backup of the required data, who is responsible for the switchover, and a method for reverting to a previous state. Record what will be checked on the production domain: pages, forms, files, integrations and addresses of the migrated site.
Review the work within the agency first
Before the client demo, go through the scenarios yourself with the contractor. This way you can separate the defect from the change in wishes and show the client a holistic stage.
The contractor provides a link to the test version, a list of completed tasks, known limitations, and a way to reproduce the test. A notice in a common system must contain a page, an action, an expected result, and an actual result. For a visual defect, please attach a screenshot and device parameters.
A conditional example of accepting a form: fill it out on a mobile device, see confirmation, find the request in CRM and check the source. If only the browser send succeeds, the entire business scenario has not yet been accepted. Detailed checks of this stage are collected in article about website integration with CRM.
After corrections, repeat exactly the affected scripts and related areas. The stage readiness criteria must be known in advance: acceptable restrictions, blocking defects, transmission composition and the person responsible for the final decision.
Evaluate a partner on the first project
To begin, choose a limited, self-contained step with clear acceptance. The pilot must show the process: clarifying requirements, assessing, demonstrating, working with comments and communicating the result. A task that is too vague will test the participants' patience but will provide little insight into the quality of production.
Rate after completion:
- What risks did the partner name before the start and how were they handled?
- How transparently the scope and plan changed.
- Is it possible to reproduce the verification of the result using the submitted materials?
- Is it convenient for the agency to continue working with source code and accesses?
- How comments were resolved and who reported obstacles.
Reviews and portfolio help in preliminary selection. Suitable for discussing the process checklist for choosing a development contractor. Based on the results of the pilot, consolidate the working rules in the transfer template for the following projects.
FAQ
Do you have to keep the development partner anonymous?
It depends on the chosen model. In a white label, agree on team presentation and communication in advance. In open subcontracting, the technical partner can participate directly. In any case, the client must understand through whom decisions are made and changes are agreed upon.
Can you subcontract only part of the development?
Yes, if the stage has input materials, an independent result and a person responsible for combining it with the rest of the project. For the interface and API, agree on an exchange contract and joint test in advance. Otherwise, both parts may be ready separately, but not work together.
What if the client contacts the developer directly?
Retain technical communication if permitted by project rules. Record requests that affect the volume and timing in the common system and transfer them to the person responsible for approval. The decision should not be lost in personal correspondence.
Who should own the source code and manage the domain?
Identify owners before work begins and ensure access to authorized representatives. To transfer a project, you need source code, instructions and the ability to manage the infrastructure. Rights and commercial terms are fixed by the parties separately.
Sources
- NBM-IT: agency partnership models.
- GitHub Docs: Organizational Repository Access Roles.
- GitHub Docs: Securing branches.
Sources verified October 2, 2026. Handover package, role table and pilot order - recommendations for organizing work; they do not describe the results of a specific NBM-IT project.