Delivery framework
Project delivery is governed by the confirmed scope, schedule, payment terms, content readiness, access, review rounds, testing requirements, third-party dependencies, and launch responsibilities.
Delivery may involve publication on a platform, transfer of files, configuration within the client’s account, collaborator access, documentation, or another method stated in the project agreement.
Project intake and requirements
Accurate delivery begins with clear project information. The client should provide business goals, target audience, required pages, current platform, content status, functionality, integrations, products, payment or shipping requirements, and expected delivery needs.
Requirements discovered after approval may change scope, timing, and pricing.
Client content responsibilities
The client is responsible for supplying accurate, lawful, complete, and approved text, images, videos, product details, prices, policies, brand assets, testimonials, and other content required for the project.
Content should be provided in usable formats and through an agreed method. The company may organize or integrate supplied content but is not responsible for independently verifying its truth, legality, ownership, or regulatory compliance.
Placeholder content may be used during implementation, but final launch should not occur until the client approves the published content.
Accounts, access, and credentials
The client should maintain ownership of domains, hosting, Shopify, payment-provider, shipping, analytics, email, application, and other business-critical accounts.
Collaborator access, role-based permissions, and account invitations should be used instead of shared master passwords when available.
The client is responsible for recovery methods, billing status, subscriptions, and removal or rotation of project access after completion.
Review rounds and approvals
Review stages allow the client to verify structure, content, responsive behavior, and functionality within the confirmed scope.
Feedback should be consolidated and submitted by the authorized decision-maker. Conflicting feedback, repeated reversals, or new requirements may delay delivery and require additional fees.
Written approval of a stage allows the project to proceed. Changes to approved work may be treated as additional work.
Testing responsibilities
Testing may include navigation, links, forms, responsive layout, content display, agreed integrations, and launch-critical settings.
The client must also review business-specific information, prices, products, tax settings, payment setup, shipping rates, policies, consent requirements, legal claims, and administrative workflows.
Testing can reduce risk but cannot guarantee that a website will be error-free, uninterrupted, compatible with every future browser or device, or unaffected by later third-party changes.
Launch preparation
Launch may depend on domain or DNS changes, platform publication, Shopify Markets, payment-provider approval, shipping configuration, inventory, applications, email authentication, analytics, and other merchant-side settings.
The company may assist with agreed launch tasks but does not control the approval, timing, availability, or technical operation of third-party providers.
The client should not authorize launch until business information, policies, products, pricing, forms, and account ownership have been reviewed.
Handover and final delivery
Handover may include publication of the approved website, transfer of agreed files, administrator or collaborator access, configuration notes, and other deliverables stated in the scope.
Internal working files, unused concepts, proprietary development tools, third-party licenses, premium assets, and source files are not included unless expressly listed.
Final transfer or launch may be conditioned on payment of undisputed amounts due under the project agreement.
Acceptance and post-delivery review
The client should inspect delivered work promptly and report reproducible scope-based implementation issues within the agreed review or correction period.
Use, publication, written approval, instruction to proceed, or failure to report issues within the agreed period may be treated as acceptance, subject to the written agreement and applicable law.
Post-delivery requests that change content, design, functionality, integrations, or platform configuration are additional work unless included in support.
Maintenance and support
Ongoing maintenance is separate unless expressly included. Maintenance may cover content updates, technical corrections, layout adjustments, platform support, or other defined work.
Support does not automatically include emergency availability, unlimited changes, third-party fees, malware remediation, hosting administration, or compatibility work after external updates.
Maintenance scope, response expectations, included time, exclusions, renewal, and cancellation should be documented.
Backups and recovery
The client should maintain current backups of website files, content, product data, customer data, theme code, and account recovery information.
Before major changes, migration, or launch, the client should confirm that an appropriate backup or duplicate environment exists where supported.
Unless a specific backup service is included, the company is not responsible for permanent archival or restoration of client systems after project completion.
Third-party dependencies
Themes, applications, APIs, domains, hosting, payment services, shipping tools, browsers, devices, and other external systems may change without notice.
Future compatibility work, provider outages, subscription lapses, policy changes, discontinued features, and external security incidents are outside the original project unless expressly included.
Delivery delays and rescheduling
Client delays in content, access, approvals, payment, or decisions may extend the schedule and require rescheduling.
External delays may include application approval, DNS propagation, payment-provider verification, platform incidents, vendor response, and force majeure events.
The company should communicate material changes to the expected schedule when reasonably possible, but an estimated date is not a guarantee unless expressly stated.
Questions about this page
Include the relevant policy name, project reference, invoice reference, or privacy request details so the inquiry can be reviewed accurately.