1. Application and definitions
This schedule supplements the accepted master terms for $PROJECT_SCOPE and $DELIVERABLES. “Website” means the agreed site or web presence. “Launch” means approved publication in the identified environment. “Maintenance” means only the ongoing tasks expressly listed. “Hosting Manager” means BlueDotHost for DealDot Website/Web Presence services; infrastructure providers may be separate third parties.
The Engagement should specify the platform, page inventory, functions, content sources, accessibility objectives, integrations, ownership/license model and exclusions. A website build does not automatically include SEO campaigns, email hosting, custom applications, domain purchase, legal drafting or ongoing editing.
2. Design, content and development
Identify discovery inputs, design direction, responsive requirements, navigation, contact paths and any project galleries. Client approves factual claims, service areas, licenses, permissions, photographs and testimonials. DealDot prepares the agreed design and implementation using that approved information.
State the number and scope of revision stages, who consolidates feedback and which outputs are reviewable. New functionality, significant content changes after approval or an expanded page inventory require a Change Order. Editable files, custom code, administrative access and export formats must be identified rather than assumed.
3. Access, dependencies and delivery
Client provides authorized access to current site, domain, DNS and required services through agreed channels. Identify who controls each account and who can approve changes. Client retains authority over its business domain and third-party accounts unless a different arrangement is expressly accepted.
Milestones and any committed date are $DATE, subject to the accepted dependencies and change process. The Engagement must distinguish design review, content review, functional testing and launch approval. A fixed completion period or particular number of billing cycles is not supplied by this schedule.
4. Testing, acceptance and launch
Agree a test checklist covering the scoped devices, links, forms, redirects, permissions and integrations, and objective acceptance criteria. Client tests business workflows and verifies the accuracy of business information. Report supported deviations through the agreed review process; changes in preference are addressed separately.
Launch requires the authorized approval specified in the SOW and readiness of the hosting environment. Coordinate DNS changes, redirects and existing services to reduce disruption. Propagation, third-party review and external outages can affect timing. No promise of zero downtime or continuous availability arises from launch coordination.
5. DealDot and BlueDotHost responsibilities
DealDot handles the design, development, content or web-presence work included in its Engagement and coordinates the hosting needs associated with that work. BlueDotHost is the Hosting Manager. Its authorized administration, technical scope, provider arrangements, billing and support responsibilities must be recorded in the Engagement or a separately accepted hosting document.
Do not assume BlueDotHost is a party to DealDot’s contract, that DealDot owns the underlying infrastructure, or that either entity guarantees the other’s unspecified obligations. Record whether Client contracts with or pays BlueDotHost directly, whether DealDot coordinates communications, and who may instruct the Hosting Manager. A service-level promise applies only if issued and accepted by the responsible party.
6. Hosting, domains and renewals
Identify the host environment, domain registrant, registrar, DNS administrator, renewal responsibility, renewal dates and any email service affected by DNS changes. Domain ownership, hosting, email and website maintenance are distinct responsibilities. Client should maintain accurate account contacts and approved access controls.
No uptime SLA, response time, storage limit, renewal fee or automatic-renewal rule is invented here. Set $HOSTING_SCOPE, $SUPPORT_BOUNDARIES, $PRICE and any renewal terms in the responsible party’s accepted document. Third-party infrastructure rules and license conditions apply to their services without creating unagreed DealDot obligations.
7. Backups, security and maintenance
State who maintains backups, what is covered, frequency, retention, storage location, restoration process and any recovery objectives. A backup exists only to the extent actually configured; no universal recovery or data-loss guarantee is supplied. Agree whether an independent Client copy or export is possible and required.
Define patching, monitoring, certificate management, access control and incident contacts for the selected platform. Client remains responsible for authorized users and changes made outside agreed maintenance. DealDot and BlueDotHost each perform the security tasks they accept. Platform restrictions may limit customization, plugin access or export.
8. Ongoing changes and external services
After launch, updates, additional content, software renewals and support are included only as stated in $MAINTENANCE_SCOPE and $SERVICE_TERM. Classify defect corrections, routine updates and new work separately. External booking, payment, analytics or assistant integrations require agreed ownership, data notices, configuration and test responsibilities.
Client must notify the relevant contact when its business information changes. Third-party discontinuation or incompatible updates may require a revised approach and approved additional scope. No unlimited support, universal compatibility or permanent feature availability is promised.
9. Ending services and transition
Before cancellation or a migration, identify services that will continue, those that will stop, hosting authority, renewal status, available exports and any paid transition assistance. Ending DealDot work does not automatically terminate a separate BlueDotHost or infrastructure arrangement. Coordinate the effective dates expressly.
Access transfer, domain changes, content export, migration and backup retention must be agreed with the responsible party. Some platforms or licensed materials may not transfer in editable form. Define $TRANSITION_SCOPE and $DATA_DISPOSITION; do not assume a migration promise, deletion deadline or refund. A lawful suspension must follow accepted terms and should account for safety, security and affected dependencies.