Business objective
What the site should help the owner achieve: credibility, lead capture, publishing, utility or sales support.
Playbook live
Playbook 01
Updated 18 Jul 2026
Web systems · SEO · Release operations
Website Delivery System
A repeatable system for taking a website from vague request to finished delivery: structure, static architecture, performance, SEO, QA, release and handover—all designed for practical execution rather than theory.
01 · When to use
Best when speed, clarity and control matter more than a heavy CMS.
This playbook is designed for brochure sites, personal sites, project microsites, operational utilities and spreadsheet-assisted content systems where the delivery speed and maintainability of a static setup create more value than a complex backend.
Use it when the scope is understandable, the content model can be made explicit, and the owner benefits from GitHub-based deployment or lightweight editing workflows. It also works well when performance, SEO and clean handover matter.
Do not force this playbook onto use cases that clearly need multi-user editorial workflows, deep backend logic or large-scale transactional functionality.
02 · Required inputs
Good websites are easier to build when the operating assumptions are explicit.
The playbook starts by collecting enough clarity to avoid endless redesign or patchwork implementation.
Core pages and assets
Required pages, images, logos, copy blocks, structured datasets and language scope.
Deployment and editing model
Domain, hosting path, repo ownership, update method and whether Sheets or files will power content updates.
Success constraints
Performance thresholds, SEO expectations, device priorities and handover requirements.
03 · Delivery workflow
Move from structure to release in seven visible stages.
Frame the scope
Define audience, goals, site map, page list and update responsibilities before any design choices harden.
Clarity firstChoose the architecture
Select static files, sheet-driven generation or hybrid patterns based on content complexity and maintenance needs.
Right-fit systemBuild the design system
Create shared layout rules, spacing, components, typography hierarchy and reusable UI blocks.
ConsistencyImplement content and SEO
Write semantic HTML, metadata, schema, internal links and clear content structure from the start.
Search readinessOptimize performance
Reduce blocking assets, improve image handling, preserve mobile usability and verify Core Web Vitals directionally.
Speed mattersRun QA and release
Test links, forms, responsive states, dark mode, indexability and domain setup before launch.
Launch confidenceHandover cleanly
Deliver only the changed files, note hidden files, explain the update workflow and define what is safe to edit.
Maintainability04 · Decision rules
Use the simplest architecture that protects future maintenance.
R-01Always
Make the content model visible early
Hidden assumptions about pages, sections, fields or update ownership create rebuild work later.
- Rule
- Before building, define what can change, who changes it and where that source lives.
- Why
- Architecture follows the update model, not only the visual design.
R-02Prefer
Static first, complexity only when justified
Many business sites overpay in complexity for problems they do not actually have.
- Rule
- Default to static delivery unless dynamic behavior clearly changes business value.
- Why
- Static systems are fast, stable and easy to inspect.
R-03Protect
Generated files should not become manual editing targets
When outputs are generated, editing them directly creates future overwrites and confusion.
- Rule
- Document the true editable source: template, sheet, data file or component.
- Why
- Durable systems preserve source-of-truth discipline.
R-04Require
SEO and performance are part of delivery, not post-launch decoration
Retrofitting fundamentals later usually costs more and leaves inconsistent implementation.
- Rule
- Ship with metadata, schema, sitemap, robots and responsive checks.
- Why
- Launch-ready means technically ready, not only visually complete.
R-05Prefer
Patch-based updates for ongoing improvements
Most maintenance cycles only change a subset of files and should be communicated that way.
- Rule
- Deliver changed files only, and call out hidden files explicitly.
- Why
- This reduces confusion during manual GitHub uploads and keeps updates clear.
R-06Keep
The handover process as lightweight as the build
A technically good site still fails operationally if the owner cannot update it.
- Rule
- Explain repo structure, update flow, content boundaries and post-launch care in plain language.
- Why
- Delivery is complete only when the system remains usable after handoff.
05 · Definition of done
A website is done when it is clear, stable, searchable and handover-ready.
Page system complete
Core pages, navigation and information architecture are final enough to support the intended user journey.
Responsive and usable
Important screens work across desktop and mobile, including dark-mode or input states if present.
Search foundation shipped
Titles, descriptions, canonical tags, sitemap, robots and essential schema are present.
Critical bottlenecks addressed
Obvious render-blocking, heavy media and broken image behavior have been reduced or fixed.
Domain and deployment verified
Live URLs, custom domain setup and indexability basics have been checked.
Owner can maintain it
The owner understands what files matter, how to update them and which parts should not be edited directly.
06 · Release checklist
The final release should be procedural, not improvised.
Repository
- Confirm final folder structure.
- Only changed files in patch updates.
- Call out hidden files explicitly.
SEO
- Title and description per page.
- Canonical URL correct.
- Sitemap and robots updated.
Experience
- Responsive states checked.
- Broken links resolved.
- Form, search and theme states verified.
Performance
- Large images optimized.
- Blocking libraries reviewed.
- Mobile bottlenecks addressed first.
Deployment
- Domain points correctly.
- HTTPS works.
- Public pages are reachable.
Handover
- Owner knows editable sources.
- Generated files are identified.
- Next-step maintenance advice included.
07 · Common failure modes
Most problems repeat. A playbook exists to catch them sooner.
Editing the wrong source
Manual edits go into generated pages instead of templates or data, then disappear on the next sync.
SEO added too late
Metadata, schema and internal linking are postponed until the site is already considered “finished.”
Performance fixes break the content
Heavy assets are removed correctly, but key banners, product images or proof elements disappear too.
Handover is too technical
The implementation works, but the owner receives instructions they cannot actually follow in practice.
Patch updates are unclear
Too many unchanged files are re-sent, or hidden files are omitted without explanation.
Scope grows without architecture review
A simple site accumulates features until the original update model no longer fits cleanly.
08 · Next playbooks
This is the first reusable operating document in the library.
The next playbooks should capture the same level of rigor for growth measurement, automation and freelance delivery.
Growth & Measurement playbook
Turn campaign review, KPI hierarchy and anomaly response into a reusable operating method.
Automation & AI playbook
Document Apps Script pipelines, GitHub Actions and shared AI working structures.
Freelance Delivery playbook
Extract discovery, pricing, scope control and handover rules into a public-safe system.
Playbook status
First playbook complete.
The Website Delivery System is now the first public playbook in KhaiTriOS, capturing a reusable method instead of only describing finished projects.