What Development Deliverables Should Be Provided to the Client?

What Development Deliverables Should Be Provided to the Client?

At the end of an outsourced development project, the client receives the development results. However, it is not always clear which materials are required for the project to be considered fully handed over.

Source code alone may not be enough. The client may also need editable design files, server and domain accounts, deployment instructions, admin manuals, test results, and external service configurations to continue operating the service.

From the agency's perspective, the client may request documents and materials at the end of the project that were never included in the original agreement. The client may consider those materials standard deliverables while the agency sees them as additional work.

There is no single deliverable list that applies to every development project. Required materials depend on the project size, contract, technical structure, and the team responsible for operation.

The important point is to agree on deliverable types, formats, delivery dates, ownership, and acceptance criteria during the contract and kickoff stages, not after development is complete.

In this article, we will review the main deliverables to consider in outsourced development and the standards required for a reliable handover.

1. Development deliverables include more than completed screens

The final website or application visible to the client is only one part of the result. The service also depends on source code, servers, databases, external services, designs, and operating policies.

Development deliverables can therefore include both the results produced during the project and the materials required to operate or modify the service.

Common deliverables include:

• Source code and repositories
• Editable design files and design systems
• Server, domain, cloud, and external service accounts
• Deployment and development environment documentation
• Database structure and API documentation
• Admin and operations manuals
• Test results and known issues
• Requirements, feature specifications, and screen designs

Not every project requires all of these materials. However, the contract should clearly state which items will and will not be provided.

2. How should source code be delivered?

Source code is one of the most important development deliverables. However, sending one compressed file may not be sufficient.

If the project was developed in a version control repository, the teams should decide how repository ownership or access will be transferred. They should also confirm which branch contains the final code and whether it matches the deployed version.

A source code handover may include:

• All frontend, backend, and admin repositories
• A tag or commit identifying the final deployed version
• Project setup, execution, and build instructions
• Required libraries and version information
• Environment variable names and configuration instructions
• External service and API integration locations
• Components not included in the source code

Sensitive information such as passwords, API keys, and certificates should not be stored directly in the source code. They should be transferred through a secure system, and unnecessary access should be removed after handover.

3. Design files require editable originals and usage rights

Design deliverables may appear unnecessary once the screens have been developed. However, editable originals are required when the client needs to add screens or revise the design later.

Design deliverables may include:

• Editable source files for each screen
• Logos, icons, images, and other visual assets
• A design system covering colors, fonts, spacing, and components
• Responsive and mobile layouts
• User flows and prototypes
• License information for paid fonts and images

The team should verify whether externally purchased images, icons, fonts, and templates can continue to be used by the client. Receiving a file does not always transfer all legal usage rights.

4. Accounts and access should be organized under client ownership

When operational accounts exist only under an agency or individual developer, the client may face serious problems after the project ends. The service may become inaccessible if the contact changes or the agency is no longer available.

Review accounts such as:

• Domain registration and DNS management
• Cloud servers and hosting
• Databases and file storage
• Apple and Google app stores
• Payment, SMS, email, and notification services
• Analytics, error tracking, and monitoring tools
• Source code and design repositories

Whenever possible, accounts should be created under the client's ownership from the beginning, with the agency receiving the access required for development.

If an agency-owned account was used, ownership should be transferred or the client should be added as the highest-level administrator. Passwords should be shared through a secure password management system rather than ordinary chat.

5. Deployment documentation allows another developer to operate the service

Even when the source code has been transferred, maintenance is difficult if no one knows how to run or deploy it. A project that depends on one developer's memory becomes risky when that person is unavailable.

Deployment and environment documentation may include:

• How to configure a local development environment
• The difference between test, staging, and production environments
• Build and deployment procedures
• Server, database, and storage architecture
• Where environment variables and secrets are managed
• Scheduled and automated task configurations
• How to inspect logs and service health
• Rollback or recovery procedures

The documentation does not need to be unnecessarily long. It should contain enough information for another developer to run, understand, and deploy the service.

6. API and database documentation may be required

API documentation is especially important for mobile applications, external integrations, and projects where multiple systems exchange data.

API documentation may include endpoints, request methods, authentication, parameters, responses, error codes, and examples. If the project depends on external APIs, the current version and associated accounts should also be recorded.

Database documentation may describe important tables, field meanings, relationships, backup processes, and the location of personal information.

Not every field requires extensive documentation. However, core service data and structures related to personal information, payments, and orders should be explained during handover.

7. Admin and operations manuals are also important deliverables

A completed service does not operate itself. The client must be able to manage members, content, orders, payments, notifications, and reports.

An admin or operations manual may explain:

• Admin login and permission management
• Member and content management
• Order, payment, and refund processing
• Notification and message delivery
• Data search and export
• Common operational errors and responses
• Situations that require development support

The manual may be provided as a document with screenshots, a short video, or an online guide.

The important question is whether the actual operations team can perform its work using the provided material.

8. Provide test results and known issues

Not every limitation disappears when a project is completed. The current version may still contain low-priority limitations or improvements scheduled for a later phase.

These items should be documented transparently as test results and known issues.

Testing deliverables may include:

• Tested features and environments
• Results of major user scenarios
• Discovered issues and resolution status
• Remaining known issues
• Unsupported devices or browsers
• Performance or security review results
• Client acceptance results and approval records

A known issue list is more than a list of defects. It helps the client understand the current service condition and prioritize post-launch work.

9. Distinguish file delivery from ownership and usage rights

Receiving a file may not automatically transfer every legal right related to it. The contract should define ownership and usage rights for source code, designs, documentation, and data.

The teams should review:

• Who owns the completed work after payment
• Usage conditions for reusable modules previously owned by the agency
• Licenses for open-source libraries
• Licenses for paid fonts, images, and plugins
• Ownership and processing rules for client and personal data
• Whether the agency may publish the work in its portfolio

This does not mean every right must always be transferred. The scope of rights should fit the project while ensuring that the client has the authority required to operate the service.

10. Manage deliverables with a list and acceptance criteria

At the end of the project, simply stating that all materials have been delivered is not enough. The teams should confirm which files were provided and whether the client can open and use them.

A deliverable list may include:

• Deliverable name and description
• File format or storage location
• Final version and creation date
• Planned and actual delivery dates
• Owner and reviewer
• Acceptance status and required corrections
• Ownership or access transfer status

The source code should run, editable design files should open correctly, and transferred accounts should be accessible. Acceptance should confirm practical usability, not only the existence of a file.

Development deliverable handover checklist

1. Confirm the deliverables agreed upon in the estimate and contract
2. Verify that the source code matches the final deployed version
3. Review editable design files and third-party licenses
4. Transfer server, domain, store, and external service ownership
5. Receive development environment and deployment documentation
6. Review API information and core data structures
7. Have the operations team review the admin manual
8. Confirm test results and known issues
9. Record the acceptance and approval status of each deliverable
10. Remove unnecessary external access and shared links

Agree on deliverables before the project ends

Deliverable disputes may appear at the end of a project, but they usually begin with missing agreements at the start.

The client may assume that every material required for operation is included, while the agency may believe the contract covers only feature implementation.

The estimate and contract should therefore define deliverable types, formats, delivery dates, ownership, and acceptance criteria. If deliverables change during the project, the change should also be recorded.

Deliverable handover and acceptance are part of the project flow

Outsourced development does not end when features are completed and deployed. The client must safely receive the results and operational access required to maintain and improve the service.

Pronika helps connect requirements, files, tasks, account-related records, deliverables, acceptance, and approvals within one project flow. When both sides can see what was delivered, when it was delivered, and who accepted it, they retain the same evidence even after the project is complete.