Corporate Website Deliverables: Designs, Assets, and Code

Many delivery disputes are not caused by a vendor intentionally withholding files. They begin because the project scope says only “complete the website design” or “deliver the website source code.” The client assumes it will be able to maintain the website independently, while the vendor assumes it only needs to finish the agreed pages. These interpretations may not collide until the final payment is due, when it is often too late.

A deliverables checklist turns “complete” into verifiable files, accounts, and responsibilities. The list varies by engagement model: a UI-only project should not be assumed to include front-end code, while front-end development does not automatically include an admin system, server access, or every third-party license.

01 Confirm Which Service You Are Buying

A design-only project primarily delivers structure, page visuals, interaction states, and design guidelines. A front-end project adds runnable pages and build code. Complete website development may also include a CMS, server deployment, domain configuration, analytics, and launch migration. Combining all three models in one quotation makes assumed inclusions especially likely later.

02 Design Files: A Figma Link Is Not the Finish Line

Editable source files should be held in the client's account or a mutually approved team workspace, not provided only as a read-only link. Pages should reflect the final approved version rather than mixing in many rounds of discarded drafts. Components, colors, typography, grids, and spacing need at least basic naming so future designers can continue the work.

Responsive deliverables should define breakpoints and adaptation rules. Drawing only one desktop home page and asking developers to adapt it for mobile is not complete responsive design. Provide key mobile designs where structure changes substantially; use rules and examples for repeated templates.

□ The final page list matches the Figma pages one to one;

□ Desktop, mobile, and any required tablet states;

□ Navigation, modals, forms, filters, empty states, error states, and loading states;

□ Component library and rules for colors, fonts, icons, and images;

□ Prototype links, interaction notes, and complex motion specifications;

□ Approved versions stored separately from exploratory drafts.

03 Assets and Licensing: Downloadable Does Not Mean Commercially Licensed

The source of every Logo, icon, illustration, photograph, video, font, sound effect, and 3D asset should be clear. Client-provided assets, vendor-created assets, paid libraries, and open-source resources have different rights. For fonts in particular, confirm whether the license applies to the final client, the website domain, or only the designer's account.

A short asset register should accompany delivery, recording the file name, source, license type, modification rights, and renewal requirements. Without one, a new team may be unable to determine which resources can still be used years later.

04 Front-End Source Code Must Be Ready for Handoff, Not Just a Folder of Files

Source-code delivery should include the repository, a stable branch, dependency lockfiles, sample environment variables, build commands, and deployment instructions. If the project relies on private components, paid plug-ins, or the vendor's internal scaffolding, specify whether the client may continue using and modifying them.

Truly transferable code allows a new developer to start it locally and create a production build by following the documentation, without verbal help from the original team. Real secrets should not be delivered, but the documentation must identify which secrets exist, who holds them, and how they are configured.

• Ownership of the Git repository or a complete commit history;
• README plus local setup, build, deployment, and rollback commands;
• Dependency versions and lockfiles;
• Sample environment variables without real passwords or keys;
• Notes on routing, components, data APIs, and major directories;
• List of third-party SDKs, plug-ins, and licenses;
• Known issues and currently unsupported scope.

05 CMS and Content: Publishing Articles Is Not Enough

When an admin system is included, deliver administrator accounts, roles and permissions, content models, and operating instructions. Corporate websites usually contain more than articles: products, solutions, case studies, team profiles, downloads, and multilingual fields may all be involved. Before acceptance, verify whether each content type can be previewed, ordered, scheduled, withdrawn, and rolled back.

Content-entry responsibility must also be explicit. Is the vendor only building templates, or migrating all existing materials? Which areas can the client edit later? Do complex visual modules require development support? Many sites have an admin system but remain difficult to maintain because their content model was not designed for real operations.

06 Archive Accounts, Domains, and Deployment Information

As a general principle, accounts for the domain, DNS, server, CDN, email, analytics, Search Console, maps, SMS, and form notifications should be created by the client entity or at least give the client the highest level of access. A vendor may configure them but should not be the sole controller.

After launch, archive DNS records, the SSL certificate method, backup strategy, monitoring access, and incident contacts. If the website runs on a shared vendor server, define the migration process, export format, migration fees, and the time allowed to handle data after the relationship ends.

07 Complete Acceptance with an Independent Operation Test

Final acceptance should cover more than whether pages open. Ask the client or a third party to follow the delivery documentation and independently clone the source code, start it locally, edit one item of content, publish to a test environment, restore a backup, and view analytics. Every step that still requires an ad hoc action from the original vendor reveals a handoff gap.

The deliverables checklist should be an attachment to the contract or requirements confirmation and remain updated at every stage. Creating it on the final day can only record files that already exist; it cannot recover permissions, documentation, or content models that were never built.

Frequently Asked Questions

Does a read-only Figma link count as delivery?

It is generally not complete source-file delivery. At minimum, confirm that the client can copy or hold the editable file and retain the final components, pages, and necessary version history.

Must front-end source code include Git history?

Preferably. A complete commit history helps teams understand changes and roll back. If the contract covers only final source code, it should still include a buildable version, dependency lockfiles, and documentation.

Must purchased fonts and images be transferred?

It depends on the license. Many third-party resources cannot be transferred directly; the client may need to purchase or obtain its own license. Record each item separately.

Does the website admin system need an operating manual?

It is recommended. A simple system may use illustrated instructions or a recording; a complex content model should document roles, publishing workflows, field meanings, and common issues.

Should all source code be delivered before the final payment?

Payment and delivery milestones should follow the contract. A common approach is to accept the runnable product and deliver complete source files and formal permissions after final payment, but the exact arrangement must be explicit.