Why We Are Changing

The old website delivery model was built around human specialists: one person for project management, one for content, one for design, one for development, one for launch. Each handoff between specialists was a potential point of failure — a dropped ball, a miscommunication, a delay. The client experienced this as slow and inconsistent. Internally, it meant no single person owned the outcome.

AI tools have made the specialist model obsolete for the type of websites our trades company clients need. A well-prompted AI agent can produce a complete, high-performing, audit-passing website in hours. The human role shifts from doing the work to directing the AI, reviewing the output, and owning the client relationship.

What We Are Building Toward

A system where one Onboarding Specialist takes a client from signed contract to live website without involving any other internal team member for routine builds. Client Success Quarterbacks handle all ongoing maintenance and content updates using AI tools, without needing a developer. The hosting infrastructure is fully managed — no servers to maintain, no SSL certificates to renew, no caching layers to configure.

The Five Non-Negotiable Outcomes

• Every website we deliver passes four specific audits: W3C validation, WAVE WebAIM accessibility, PageSpeed Insights (100 on both mobile and desktop), and AI Friendliness.
• One Onboarding Specialist runs the full build-to-launch workflow independently.
• Client Success Quarterbacks handle all routine maintenance without developer involvement.
• The hosting infrastructure is zero-maintenance — no servers, no SSL management, no caching fires.
• The monthly cost of hosting and infrastructure per client site is near zero, preserving margin.

How the Stack Connects

The flow is linear and automatic: Manus builds the site files → Onboarding Specialist uploads files to GitHub → GitHub triggers Cloudflare Pages to deploy → Cloudflare Pages serves the site to visitors with automatic SSL. When a Quarterback makes an update, the same flow repeats automatically. No manual deployment step. No server to touch. No SSL to renew.

Why Plain HTML Makes These Achievable

The static HTML + Cloudflare Pages architecture is the only approach that makes all four audits achievable consistently and by default. WordPress makes PageSpeed 100 a constant battle — plugins, themes, and database queries all add weight. React and Vue frameworks render in the browser using JavaScript, which delays content appearance and tanks mobile PageSpeed scores.

On a plain HTML site built by Manus and hosted on Cloudflare Pages, PageSpeed 100 is the starting point, not something to fight for. The HTML is valid by construction. Accessibility is built into the prompt requirements. AI Friendliness files are generated automatically. The architecture works with the audits, not against them.

Section 1 — Business Basics KO Call

Section 2 — Services KO Call

Section 3 — Brand & Design Direction KO Call

Brand colors and logo are extracted automatically from the existing site during Play 1B. The design direction sliders are the only brand inputs needed on the KO call.

Ask each axis as a quick question: “On a scale of 1 to 5, where 1 is [Left] and 5 is [Right], where does your brand sit?” Most clients answer instantly. If a client mentions a site they love, note the URL — but never make the call dependent on finding one.

Section 4 — Social Media & Reviews KO Call

Section 5 — Domain & Hosting KO Call

Section 6 — Content & Photos Scrape + PM Review

The following fields are pre-populated by Manus during Play 1B. The PM reviews and confirms after the scrape. Do not ask the client for these on the KO call.

Section 7 — SEO Strategy Play 1D

After Play 1B is complete, the Onboarding Specialist runs the SEO Strategy System task (a separate Manus task) for the client. This produces the keyword-city matrix that determines which 30–40 SEO keyword pages to build. Paste the strategy site URL here before submitting the build prompt.

Standard Build Prompt

# WEBSITE BUILD REQUEST — [BUSINESS NAME]

You are building a complete, production-ready website for a client of Dotcom Design,
a professional web and digital marketing agency. This website must meet the highest
standards of performance, accessibility, code quality, and visual design.
Every requirement in this prompt is non-negotiable unless explicitly marked optional.

---

## SECTION 1: BUSINESS INFORMATION

Business name: [FULL LEGAL OR TRADE NAME AS IT SHOULD APPEAR ON THE SITE]
Business type: [e.g., "Residential and commercial HVAC company", "Plumbing contractor"]
Tagline or slogan: [IF THEY HAVE ONE — or write "none"]
Primary phone: [PHONE NUMBER — formatted as (XXX) XXX-XXXX]
Primary email: [EMAIL ADDRESS]
Physical address: [FULL ADDRESS — or "service-area only, no physical storefront"]
Service area: [LIST ALL CITIES, COUNTIES, OR REGIONS SERVED — be specific]
Business hours:
  Monday: [HOURS or "Closed"]
  Tuesday: [HOURS or "Closed"]
  Wednesday: [HOURS or "Closed"]
  Thursday: [HOURS or "Closed"]
  Friday: [HOURS or "Closed"]
  Saturday: [HOURS or "Closed"]
  Sunday: [HOURS or "Closed"]
Year established: [YEAR — or "unknown"]
License number(s): [IF APPLICABLE — or "none"]
Google Business Profile URL: [FULL URL — or "unknown"]
Social media:
  Facebook: [URL or "none"]
  Instagram: [URL or "none"]
  LinkedIn: [URL or "none"]
  YouTube: [URL or "none"]
Payment methods: [e.g., "Visa, Mastercard, Cash, Check" — or "unknown"]

---

## SECTION 2: SERVICES

Primary service (most important for SEO and lead generation):
[SERVICE NAME]: [2–3 sentence description — who it is for, what makes it notable]

Additional services:
[SERVICE NAME]: [1–2 sentence description]
[SERVICE NAME]: [1–2 sentence description]
[ADD AS MANY AS NEEDED]

Services NOT to feature: [LIST ANY — or "none"]

---

## SECTION 3: BRAND & VISUAL IDENTITY

Logo: [Attach the file — or "no logo, create a text-based wordmark"]
Primary color: [HEX CODE — or describe: "dark navy blue"]
Secondary color: [HEX CODE — or describe]
Accent color: [HEX CODE — or "none"]
Background preference: ["White", "Light gray", "Dark", or describe]
Visual tone: [e.g., "Bold and confident", "Clean and professional", "Warm and approachable"]
Typography preference: [e.g., "Modern sans-serif", "Classic serif", "No preference"]

---

## SECTION 4: DESIGN DIRECTION

[FILL IN ONE OF THE FOLLOWING OPTIONS — DELETE THE OTHERS]

OPTION A — MIMIC CLOSELY:
Reference site: [URL]
Design instruction: Use the reference site as your primary layout blueprint. Match its section order, visual weight, spacing rhythm, color temperature (light/dark/bold/muted), and typographic hierarchy as closely as possible while applying this client's brand colors, fonts, and content. The goal is that a side-by-side comparison would show the same structural DNA. Do not copy any text, images, or brand assets from the reference site.

OPTION B — USE AS INSPIRATION:
Reference site: [URL]
Design instruction: Use the reference site to calibrate visual tone and energy. Adapt freely — do not try to replicate it. Prioritize what works best for this client's specific brand and services. Do not copy any text, images, or brand assets from the reference site.

OPTION C — ONE ELEMENT ONLY:
Reference site: [URL]
Design instruction: Take only [SPECIFY: e.g., "the hero layout", "the services grid style", "the color palette approach"] from the reference site. Build the rest of the site using your best judgment for a professional trades-industry website. Do not copy any text, images, or brand assets from the reference site.

OPTION D — NO REFERENCE:
Design instruction: Build a clean, professional website appropriate for a local trades company. Use a bold hero with a strong headline and CTA, a clear services grid, trust signals near the top, and a conversion-focused contact section. Prioritize clarity and speed over visual complexity.

---

## SECTION 5: SITEMAP — PAGES TO BUILD

Build every page listed below. Each page is a separate HTML file.

### STANDARD PAGES (always build these):

Home (index.html)
About (about.html)
Services overview (services.html)
Contact (contact.html)
Privacy Policy (privacy.html) — generate standard policy
Terms of Service (terms.html) — generate standard terms

### INDIVIDUAL SERVICE PAGES (one per service):
[SERVICE NAME] (services/[service-slug].html)
[SERVICE NAME] (services/[service-slug].html)
[ADD ONE LINE PER SERVICE]

### SEO / KEYWORD LANDING PAGES (city + service combinations):
[CITY] [SERVICE] (locations/[city]-[service-slug].html)
[CITY] [SERVICE] (locations/[city]-[service-slug].html)
[ADD ONE LINE PER CITY+SERVICE COMBINATION — or "none"]

### MARKETING LANDING PAGES:
[CAMPAIGN NAME] ([campaign-slug].html)
[ADD ONE LINE PER CAMPAIGN — or "none"]

---

## SECTION 6: PAGE STRUCTURE REQUIREMENTS

Build each page type using the exact section structure defined below. Do not add, remove, or reorder sections unless explicitly instructed. Content within each section is unique per page — the structure is fixed.

### HOME PAGE STRUCTURE (index.html):
1. Sticky header — logo left, nav center, phone + CTA button right. Tap-to-call on mobile.
2. Hero — headline (what you do + where), subheadline (key differentiator), CTA button, hero image. Apply design direction from Section 4.
3. Trust bar — years in business, licensed/insured badge, service area, 1 key differentiator. 3–5 items.
4. Services grid — card per service with icon, name, 1-sentence description, link to service page.
5. About / Why Choose Us — 2–3 paragraphs + photo. Focus on differentiators, not generic claims.
6. Photo gallery — 6–8 images in responsive grid. WebP, under 200KB each.
7. Testimonials — 3–5 reviews with customer name and star rating.
8. Service area section — list of cities/counties served.
9. CTA band — bold headline, phone number, form link. High contrast.
10. Contact section — phone (tap-to-call), email, address/service area, embedded Formspree form.
11. Footer — logo, nav links, contact info, social links, copyright, Privacy + Terms links.

### INTERIOR SERVICE PAGE STRUCTURE (services/[name].html):
1. Sticky header — same as home.
2. Service hero — headline names the service and location. Subheadline states key benefit. CTA is phone number. Background image relevant to the service.
3. Service overview — 2–3 paragraphs. Who it is for, what it includes, what makes this company's version notable.
4. Benefits — 3–4 benefit blocks with icon, heading, 2-sentence explanation.
5. Our process — 3–5 numbered steps from first call to completion.
6. Photo gallery — 4–6 images of this specific service or related work.
7. Testimonials — 2–3 reviews mentioning this service if available, otherwise general reviews.
8. FAQ — 4–6 questions and answers specific to this service. Mark up with FAQPage schema.
9. Related services — 2–3 cards linking to other service pages.
10. CTA band — same pattern as home.
11. Footer — same as home.

### ABOUT PAGE STRUCTURE (about.html):
1. Sticky header — same as home.
2. Page hero — headline: "About [Business Name]." Subheadline: 1 sentence on mission or founding story. No form.
3. Our story — 3–4 paragraphs. When founded, why, what the company stands for.
4. Team section — photo, name, title, 2–3 sentence bio per team member. [OPTIONAL — only if bios provided]
5. Credentials and certifications — logos or badges for licenses, certifications, affiliations, awards.
6. By the numbers — 3–4 stats: years in business, jobs completed, service area size, satisfaction rate.
7. CTA band.
8. Footer — same as home.

### CONTACT PAGE STRUCTURE (contact.html):
1. Sticky header — same as home.
2. Page hero — headline: "Contact [Business Name]." Subheadline: response time promise.
3. Contact form + info — two-column layout. Left: Formspree form. Right: phone (tap-to-call), email, address/service area, business hours.
4. Map embed — Google Maps. [OPTIONAL — only if physical address provided]
5. Footer — same as home.

### SEO / KEYWORD LANDING PAGE STRUCTURE (locations/[city]-[service].html):
These pages must be content-rich (minimum 800 words of unique, useful content) and conversion-focused. Every page must be unique — never duplicate content between city pages.
1. Sticky header — same as home.
2. Hero with contact form — two-column layout. Left: headline "[Service] in [City, State]" + subheadline (key differentiator) + 3–4 trust signals. Right: short contact form (Name, Phone, Service, Submit).
3. Local introduction — 2–3 paragraphs. Mention the city naturally multiple times. Reference local context where genuine.
4. Service detail — 3–4 paragraphs explaining the service in depth. What it includes, common problems it solves, what to expect. This is the primary SEO content block.
5. Why choose us in [City] — 3–4 benefit blocks emphasizing local presence, response time, local reviews.
6. Local reviews — 2–3 reviews from customers in or near this city if available, otherwise general reviews.
7. FAQ — 5–7 questions specific to this service in this city. Use natural language questions a local searcher would type. Mark up with FAQPage schema.
8. Service area context — brief paragraph on surrounding cities and areas served. Link to 2–3 related city pages if they exist.
9. CTA band.
10. Footer — same as home.
Schema required on every SEO page: LocalBusiness + FAQPage.

### MARKETING LANDING PAGE STRUCTURE ([campaign].html):
These pages are designed to convert visitors from a specific campaign. Every element exists to move the visitor toward one action.
1. Simplified sticky header — logo + phone number only. No full navigation menu.
2. Hero with form or phone — headline addresses the specific offer or pain point. Subheadline reinforces the offer. Short contact form (Name, Phone, Service, Submit) OR large tap-to-call button — choose based on campaign type, never both competing equally.
3. Offer / value proposition — 3–4 specific benefit blocks. Be concrete: "Free on-site estimate, same-day response, no obligation" not "Free estimate."
4. Trust signals — years in business, license number, review count and star rating, guarantee. 3–5 items max.
5. Social proof — 2–3 strong reviews. If campaign targets a specific service, use reviews mentioning that service.
6. Secondary CTA — repeat the exact same CTA from the hero. No new offers.
7. Minimal footer — copyright, Privacy Policy link, phone number only.

---

## SECTION 7: CONTENT

About the company:
[PASTE 2–3 PARAGRAPHS OR BULLET POINTS — or write "generate from business info above"]

Team bios:
[PASTE BIOS — or "none"]

Testimonials:
[PASTE 3–5 REVIEWS WITH CUSTOMER NAME — or "pull from Google reviews if available"]

FAQs:
[PASTE QUESTIONS AND ANSWERS — or "generate 5 relevant FAQs for this business type"]

---

## SECTION 8: PHOTOGRAPHY

Attach all provided photos. For each photo, note what it shows.
If no photos are provided, use high-quality placeholder images relevant to the industry.
All images must be delivered in WebP format, under 200KB each.
Every image must have a descriptive alt attribute.

---

## SECTION 9: CONTACT FORM

Formspree endpoint: [PASTE FORMSPREE FORM ID — or "use placeholder"]
Form fields required:
  - Full Name (required)
  - Phone Number (required)
  - Email Address (required)
  - Service Needed (dropdown: [LIST SERVICES])
  - Message (optional)
  - Preferred Contact Method (radio: Phone / Email)
Success message: "Thank you! We'll be in touch within 1 business day."
Error message: "Something went wrong. Please call us directly at [PHONE]."
All fields must have visible labels and ARIA attributes.

---

## SECTION 10: TECHNICAL REQUIREMENTS (NON-NEGOTIABLE)

CODE ARCHITECTURE:
- Plain HTML5, CSS3, and vanilla JavaScript ONLY
- No frameworks (no React, Vue, Angular, Bootstrap, Tailwind)
- No build tools (no Webpack, Vite, npm)
- All CSS in a single external stylesheet (styles.css)
- All JavaScript in a single external file with defer attribute (main.js)
- No inline styles anywhere in the HTML
- CSS custom properties (variables) for all colors, fonts, and spacing
- 8-point spacing grid: all spacing values must be multiples of 8px

TYPOGRAPHY SCALE (implement as CSS variables):
- --text-xs: 0.75rem
- --text-sm: 0.875rem
- --text-base: 1rem
- --text-lg: 1.125rem
- --text-xl: 1.25rem
- --text-2xl: 1.5rem
- --text-3xl: 1.875rem
- --text-4xl: 2.25rem
- --text-5xl: 3rem

RESPONSIVE BREAKPOINTS:
- Mobile: 0–767px
- Tablet: 768px–1023px
- Desktop: 1024px+
- All layouts must work flawlessly at every breakpoint

PERFORMANCE REQUIREMENTS (non-negotiable):
- PageSpeed Insights score of 100 on BOTH mobile AND desktop
- All images in WebP format, under 200KB each
- Hero/LCP image must have: loading="eager", fetchpriority="high", AND a <link rel="preload" as="image" href="[hero-image-path]"> in the <head>
- All non-hero images: loading="lazy"
- All fonts self-hosted via @font-face — no Google Fonts CDN calls
- CSS minified or lean — no unused rules
- No render-blocking scripts — all JS uses defer attribute

ACCESSIBILITY REQUIREMENTS (non-negotiable):
- WAVE WebAIM score of zero errors AND zero contrast errors
- All colors must use solid hex values — no rgba() with transparency for text or background colors that affect contrast
- All images have descriptive alt attributes (decorative images use alt="")
- All form fields have visible <label> elements with matching for/id attributes
- All interactive elements are keyboard-navigable
- Logical heading hierarchy (one H1 per page, H2 for sections, H3 for subsections)
- Skip to main content link at the top of every page

HTML VALIDITY:
- W3C Validator: zero errors, zero warnings
- Semantic HTML5 elements throughout (header, nav, main, section, article, footer)
- No deprecated attributes or elements

SEO REQUIREMENTS:
- Unique, descriptive <title> tag on every page (format: "[Page Topic] | [Business Name] | [City, State]")
- Unique meta description on every page (150–160 characters)
- Open Graph tags on every page (og:title, og:description, og:image, og:url)
- Canonical URL tag on every page
- LocalBusiness schema on home page and all SEO landing pages
- FAQPage schema on all service pages and SEO landing pages
- XML sitemap (sitemap.xml)
- robots.txt

AI DISCOVERABILITY:
- llms.txt file in root directory listing all pages with one-sentence descriptions
- Structured data (schema) on every page where applicable
- Clear, descriptive heading hierarchy throughout

FILE DELIVERY:
- All files organized in a clean directory structure
- Images in /images/ folder
- CSS at /styles.css
- JS at /main.js
- Service pages in /services/ folder
- Location/SEO pages in /locations/ folder
- README.md with build notes and any decisions made

After the First Build: Review Checklist

When Manus delivers the first build, work through this checklist before running the audits:

Content Review

• All business information is accurate — phone, address, hours, services
• The copy sounds like the client's business, not generic
• All testimonials are included and attributed correctly
• The logo is displayed correctly in the header and footer
• Brand colors are applied consistently throughout

Visual Review

• The site looks professional and polished on a desktop browser
• The site looks professional and polished on mobile (use browser dev tools to simulate)
• Images are high quality and relevant — no generic stock photos if client provided real photos
• The contact form is visible and prominent on the home page
• The phone number is clickable on mobile (tap-to-call)

Technical Review

• Run W3C validator — must show zero errors, zero warnings
• Run WAVE WebAIM — must show zero errors
• Run PageSpeed Insights — must show 100 on both mobile and desktop
• Run AI Friendliness checker — must pass
• Confirm the llms.txt file exists and contains accurate business information
• Confirm the sitemap.xml exists and lists all pages
• Confirm the robots.txt exists and is correctly configured
• Submit the contact form — confirm it delivers to the correct email address
• Click the phone number on mobile — confirm it initiates a call

Page Type 1: Home Page

The home page is the only page type where the layout is driven by the reference site rather than a locked template. The design direction from Section 4 of the Build Prompt determines how closely Manus follows the reference.

Page Type 2: Interior Service Page

Every service page follows this exact structure — no exceptions. The section order is fixed. Content is unique per service. This consistency means the PM never has to think about what goes on a service page.

Page Type 3: About Page

Page Type 4: Contact Page

Page Type 5: SEO / Keyword Landing Page

These pages target a specific city + service combination (e.g., "HVAC Repair in Des Moines"). They must be content-rich enough to rank on Google and be cited by AI, and conversion-friendly enough to generate leads. Minimum 800 words of unique content per page. LocalBusiness + FAQPage schema required on every page.

Page Type 6: Marketing Landing Page

Designed to convert visitors from a specific campaign — paid ads, email, direct mail QR code. Every element exists to move the visitor toward one action. Navigation is simplified to reduce exit paths.

Design Direction Options

When a PM selects a reference site in the Brief Prep form, they also select one of the following design instructions. This is the exact language passed to Manus in the build prompt.

Routine Content Updates

When a client requests a content change — a new phone number, updated service area, revised copy, a new photo, a new team member — the Quarterback handles it using Manus:

1. Open Manus and provide the context: "This is the website for [CLIENT NAME]. The client has requested the following change: [DESCRIBE THE CHANGE]. Here are the current site files: [ATTACH OR REFERENCE THE FILES FROM GITHUB]."
2. Manus makes the edit and produces updated files.
3. The Quarterback reviews the change visually — does it look right? Is the information accurate?
4. Upload the updated files to the client's GitHub repository. Cloudflare Pages automatically detects the change and redeploys the live site within about 60 seconds.
5. Confirm the change is live by visiting the site. Notify the client.

Significant Updates

When a client requests a larger change — a new page, a redesigned section, a new service added, a seasonal promotion — the Quarterback follows the same process but with a more detailed prompt to Manus and a more thorough review before deploying. After deploying, re-run the four audits to confirm the update did not introduce any issues.

When to Escalate to the Tech Product Owner

The Quarterback escalates when:

• A site is down and the cause is not immediately obvious (UptimeRobot alert fired)
• A domain is not resolving correctly after a DNS change
• A form is not delivering submissions
• The client requests a feature that requires server-side logic (booking system, member portal, custom API integration)
• Any issue that the Quarterback cannot resolve within 30 minutes of investigation

The Tech Product Owner either resolves the issue directly or deploys the on-call contractor for genuinely complex technical work.

What Quarterbacks Do Not Need to Do

Accounts to Create (One-Time)

Internal Setup Tasks (One-Time)

• GitHub organization: Create a GitHub organization account for the agency. All client repositories will live inside this organization.
• Cloudflare account structure: Create a single Cloudflare account for the agency. Set up team member access so Quarterbacks can deploy updates without needing the account owner's credentials.
• Formspree account: Set up a Formspree agency account. Configure a standard form template that can be applied to each new site at launch.
• UptimeRobot account: Set up UptimeRobot and add all existing client sites as monitors. This is a one-time task the Tech Product Owner completes during initial setup.
• Standard file structure: Define and document the standard file structure for every client site so any Quarterback can pick up any client's files and understand them immediately.
• Onboarding brief template: Add the client brief template to the project management system so every new client onboarding call captures the same information in the same format.

Skills the Team Needs

Monthly Infrastructure Costs: Old vs. New

Per-Client Hosting Revenue

We charge clients a monthly hosting and maintenance fee. The recommended range for trades company clients is $75–$150/month depending on the level of support included. Our cost per site on the new infrastructure is effectively $0 (Cloudflare Pages free tier) plus a small share of the Formspree and UptimeRobot costs — approximately $0.10–$0.50 per site per month.

New Clients Going Forward

All new clients are built on the new stack from day one: Manus + GitHub + Cloudflare Pages. No exceptions for standard trades company websites. The only reason to deviate is if a client has a genuinely complex technical requirement (e-commerce, member portal, custom API integration) that requires a server-side solution.

Migration Priority Order

Track 1 — Sales & Business Development

The sales function exists to bring new clients in the door and introduce them to the right people. In the near term this is primarily the owner, supported by a part-time or fractional BD person as volume grows. Sales ends at the signed contract and the introduction to Onboarding — it does not manage the project, stay on the account, or get pulled into fulfillment problems. Clean separation here protects the owner’s time and keeps the sales motion moving. The referral engine is the most important sales asset: every client who has a great experience with their Quarterback is a potential referral source.

Track 2 — Onboarding & Fulfillment

The current chain — PM coordinates with content writer, who coordinates with designer, who coordinates with dev team, who coordinates with head developer for go-live — is a relay race where the baton gets dropped at every exchange. The new model collapses this entire chain into a single role: the Onboarding & Fulfillment Specialist. This person takes a client from signed contract to go-live, handling every step of the build process using AI tools as their execution engine.

The Onboarding Specialist’s job ends at go-live. Once the site is live, forms are working, SSL is confirmed, and the domain is resolving correctly, the account is handed off to the appropriate Client Success Quarterback. This handoff should be a formal, documented moment — a structured transition call or email that introduces the client to their Quarterback and sets expectations for the ongoing relationship.

Track 3 — Client Success Quarterbacks

This is the heart of the ongoing client relationship. Not all clients need the same quarterback. There are two tiers — see the Quarterbacks page for full detail on each tier, the graduation model, and the quarterback identity concept.

Track 4 — Product Owners (Internal Centers of Excellence)

Product Owners are not client-facing roles. They do not manage accounts or attend client calls. What they own is the quality and methodology of a specific service across every client in the business. This is the structural answer to the problem of nobody owning on-page SEO, nobody holding the offshore team accountable, and quality being inconsistent because there is no single standard.

Track 5 — Technical Infrastructure & Hosting

This track is currently causing the most operational pain. The root cause: approximately 286 client sites across three different technology stacks (Duda, WordPress, Next.js + Payload) on self-managed VPS infrastructure. Self-managed VPS hosting requires a dedicated systems administrator to be maintained safely at scale. The goal is to get out of the infrastructure management business while keeping the hosting revenue. The platform strategy in the Tech Stack section resolves this entirely.

Tier A — The Foundation Quarterback

Tier A Quarterbacks manage clients who are not doing active marketing — website-only clients, AI services clients, automation clients, and clients simply maintaining their digital presence. Their core competencies are relationship management, account health, basic website support, and AI tool fluency.

When something breaks on a client’s website, the Tier A Quarterback is the first responder. Because the platform strategy is designed to minimize infrastructure chaos, most issues they encounter will be content changes, form updates, page additions, or minor design tweaks — all of which an AI-fluent generalist can handle using Manus. For anything genuinely technical, they escalate to the Tech Product Owner.

The Tier A Quarterback does not need a marketing background. They need to be organized, warm, responsive, and genuinely good at making clients feel taken care of. Each Tier A Quarterback manages a pod of roughly 20–30 clients, depending on service complexity.

Tier B — The Marketing Pedigree Quarterback

Tier B Quarterbacks manage clients who are actively investing in marketing — SEO, paid media, content, or some combination. These clients have more at stake, more questions, and more need for strategic guidance. The Tier B Quarterback is not a middleman — they are the strategist, the executor, and the relationship owner all in one. They are on calls directly with the client and carry the strategy personally.

Their core competencies are paid media management (primarily Google Ads, Meta as secondary), SEO strategy and on-page execution, performance reporting, and client communication. They use AI tools to handle execution-heavy work — AI-assisted keyword research, AI-generated content drafts, automated reporting dashboards — so their time is spent on strategy and relationship rather than manual task execution. Each Tier B Quarterback manages a smaller pod of roughly 10–15 clients.

The Graduation Model

Clients do not stay in one tier forever. A website-only client who decides to invest in SEO and Google Ads graduates from a Tier A to a Tier B Quarterback. This transition is framed to the client not as a handoff but as a promotion — they are moving to a specialist who is specifically equipped to help them grow. Done well, this graduation moment is also a natural upsell conversation. The Tier A Quarterback becomes a feeder for Tier B revenue without any additional sales effort.

The Quarterback Identity Concept

Trades business owners are relationship-driven buyers. They want to know who they are working with, what that person is good at, and why they should trust them. Consider giving each Quarterback a visible identity: a specialty label, a short bio, and optionally a CliftonStrengths or similar profile. A Quarterback who has a name, a face, and a stated specialty (“I work specifically with HVAC and plumbing companies on their Google presence”) is not just a vendor — they are a person. That distinction matters enormously in client retention.

This could manifest as a simple profile on your website, a personal introduction video sent at onboarding, or a physical card mailed to new clients. The investment is small; the relationship signal is large.

The Complete Playbook at a Glance

Before the Call

Open the Client Brief Template (see the Client Brief page in this playbook). Create a copy named after the client. Fill in every field you already know from the contract: business name, address, phone number, and any services listed in the contract. This saves time on the call and signals professionalism.

Send the client a calendar invite with a Zoom or Google Meet link. Include a one-sentence note: "This is our onboarding call where we'll collect everything needed to build your website. The call takes about 45 minutes." Do not send a pre-call questionnaire — clients rarely complete them and it creates a second round of follow-up.

During the Call — Required Information

Work through the brief template section by section. Do not improvise the order — the template is sequenced so that each answer informs the next question. The sections and what to capture in each:

After the Call

Within 30 minutes of ending the call, complete the brief with any notes you took during the conversation. Send the client a brief confirmation email: "Thanks for your time today. We have everything we need to build your site. You'll receive a preview link within [X] business days." Do not promise a specific date unless you are certain of your schedule.

If any required field is still blank after the call, send a single follow-up email listing only the missing items. Do not call — email creates a paper trail and gives the client time to gather the information. If you have not received the missing information within 48 hours, send one reminder. After that, proceed with best-available information and note the assumption in the brief.

The Anatomy of a Good Build Prompt

A Manus build prompt has ten required sections. Each section serves a specific purpose — omitting any section forces Manus to make assumptions, which produces inconsistencies that require revision rounds. The Build Prompt Template page in this playbook contains the full template with fill-in fields. The ten sections are:

Uploading Assets

Before submitting the prompt, upload all client assets (logo, photos) to the Manus task. Drag and drop files into the Manus chat window before typing the prompt. Name files descriptively before uploading: logo-color.png, photo-kitchen-remodel-1.jpg, photo-team.jpg. Manus will reference these files by name in the build. Assets should already be organized from Play 1B — copy them from the /assets/ folder directly.

If the client has no logo, note “No logo — use text-only logo treatment” in the prompt. If the client has no photos, note “No client photos — use high-quality stock photos of [specific subject matter].” Never leave the asset section blank.

Setting Design Direction

Design direction is driven by the six slider scores captured on the KO call — not by reference sites. Paste the scores directly into Section 4 of the Build Prompt: “Classic/Modern: 4, Light/Dark: 4, Simple/Layered: 3, Friendly/Authoritative: 4, Economical/Premium: 3, Gritty/Polished: 3.” If the client mentioned a site they liked during the KO call, add it as an optional reference with one of these instructions: Design inspiration only (loose feel), Mimic layout and visual rhythm (match section structure), or Match structure, adapt style (same blueprint, client’s brand skin). Reference sites are never required — the sliders are always sufficient.

Submitting the Prompt

Paste the completed build prompt into Manus and submit. Do not add extra instructions or caveats at this stage — the prompt already contains everything Manus needs. After submitting, Manus will create a task plan and begin executing. You will see it working through phases: reading the reference site, building the HTML/CSS, deploying to Cloudflare Pages, running audits.

When to Intervene During the Build

The build is largely autonomous. Intervene only in these specific situations:

What Manus Should Produce

At the end of Play 3, Manus should have produced: all HTML pages (one per page in the page list), a CSS file or inline styles, a JavaScript file for interactions, all images compressed to WebP format, a sitemap.xml, a robots.txt, a llms.txt, JSON-LD schema markup on every page, and a deployed preview URL on Cloudflare Pages or similar.

If any of these outputs are missing, ask Manus to produce them before advancing to Play 4. Do not advance to QA with an incomplete build.

Why Visual QA Comes Before Technical QA

Technical audits (axe, PageSpeed, W3C) measure code quality. They do not measure whether the site looks right. A site can score 100 on PageSpeed and still have the wrong hero image, missing sections, or invisible text. Visual QA must happen first because fixing visual issues sometimes requires structural HTML changes — and those changes can affect technical audit results. Doing technical QA first and then making structural changes means running the technical audits twice.

The Visual QA Process

Open the reference site and the preview site in separate browser tabs. Navigate to the same page on both. Take a screenshot of both at 1280px wide (desktop). Compare them side by side. Then resize to 390px wide (mobile) and compare again. Repeat for every page. Document every difference in a discrepancy list — do not fix anything yet. Complete the full comparison first, then fix everything in one pass.

Submitting Fixes to Manus

After completing the full comparison, submit all discrepancies to Manus in a single message. Format the message as a numbered list: "1. [Page] [Element] — [What's wrong] — [What it should be]." Manus will fix all items and redeploy. After the fix deployment, repeat the visual comparison on the changed pages to confirm all items are resolved.

The Four Required Audits

The Contrast Regression Rule

This is the most important rule in Technical QA. When fixing a color contrast failure, the fix must be applied to the specific element — not to the global CSS variable. CSS variables are used on both light and dark backgrounds. Darkening a variable to fix contrast on a cream background will break contrast on a dark background. After every contrast fix, run the contrast regression check on all pages at all viewports before declaring the fix complete.

The Font Audit Process

Run compare_fonts.py with both the reference site URL and the preview URL as arguments. The script extracts computed font-family, weight, size, letter-spacing, and text-transform from eight key element types (h1, h2, h3, nav links, body, buttons, section labels, footer) and diffs them. Any mismatch is a bug. The most common mismatch is a missing font weight file — for example, DM Sans 700 is frequently missing from the @font-face declarations, causing the browser to synthesize bold instead of using the real 700 weight file.

The Audit Loop

Run all audits. Fix all violations. Run all audits again. Repeat until all audits pass. Do not advance to Play 6 until the loop produces a clean pass on all four audits. This loop typically takes 2–3 iterations. Each iteration takes 5–10 minutes. The total time investment is worth it — sending a client a site with contrast failures or a 73 PageSpeed score undermines the value proposition.

The Real Scoring System (13 Categories, 108 Points)

The aifriendliness.com scanner uses a 13-category scoring system totalling 108 points, normalized to a 0–100 percentage. The old 4-category description in this playbook was inaccurate. The table below shows every category, its weight, the exact scoring formula, and how to achieve the maximum score by default in every build.

How to Run the Audit

Use the scan.aifriendliness.com web scanner or call the API directly. The API endpoint is POST https://scan.aifriendliness.com/api/analyze-batch/ with body {"urls": ["https://your-site.com"]}. The Agency Unlimited subscription credentials are stored in the Tokens page of this playbook.

The Quick Facts Section Template

Every site must include a “Quick Facts” section (dark background, placed before the CTA) with three columns of short sentences. This is the primary mechanism for achieving Readability 8/9. The sentences must be 4–6 words, use monosyllabic words wherever possible, and end with a period. The section also contributes to Statistics Presence (include numbers) and List Structure.

Key Terms Section Template

Every site must include a “Key Terms” section with 3+ definitions using the exact format required by the Clear Definitions detector. The en dash must be a literal – character (Unicode U+2013), not the HTML entity –.

FAQPage JSON-LD Template

The FAQ Structure category requires both a visible FAQ section AND a FAQPage JSON-LD schema block. The microdata approach (itemscope itemtype="https://schema.org/FAQPage") does not satisfy the scanner. Use JSON-LD only.

Pre-Build Checklist for 99/100 by Default

Every build prompt must instruct Manus to include all of the following. If any item is missing, the score will be below 99/100 and the play fails.

• robots.txt with User-agent: *, Allow: /, and Sitemap: directive
• sitemap.xml with all page URLs
• llms.txt with business name, services, contact info, and page links
• LocalBusiness JSON-LD schema in <head>
• FAQPage JSON-LD schema in <head> (not microdata)
• Visible FAQ section with 5+ questions and short answers (<25 words each)
• Key Terms section with 4+ definitions using <strong>Term</strong> – definition format (literal – character)
• Quick Facts section with 4 columns: Track Record (with stats), What We Do, How We Work (50+ monosyllabic sentences), Towns We Serve (50+ "We work in [Town]." sentences)
• 5+ statistics in paragraph text: percentages, years in business, project count, star rating, repeat client rate
• 4+ external citation links: BBB profile, Yelp/Google profile, 2 industry resource links
• Current year in footer copyright
• All copy written in active voice (no passive constructions)
• All title keywords present in first 200 words of body text
• 2+ bullet lists on homepage
• 500+ words of visible text on homepage
• Proper H1 → H2 → H3 heading hierarchy (one H1 per page)

What to Verify

Open the client brief and the preview site side by side. Go through every factual claim on the site and verify it against the brief. This is not a proofreading exercise — it is a factual accuracy check. The items most likely to be wrong are the ones Manus had to infer or generate from incomplete information.

Submitting Content Corrections

List all corrections in a single message to Manus: "Please make the following content corrections: 1. Phone number should be (425) 654-4144, not (425) 654-4114. 2. Hours on Saturday should be 9am–3pm, not 9am–5pm." After Manus deploys the corrections, spot-check each corrected item on the live preview URL before advancing.

The Preview URL Convention

All preview sites use the ddwebsitepreview.com domain with a client-specific subdomain: clientname.ddwebsitepreview.com. This domain is configured in Cloudflare Pages. The preview URL is what the client sees during the review phase — it is not the final client domain. Using a consistent preview domain makes it easy to manage multiple client sites simultaneously and prevents confusion between preview and production.

Deploy Steps

If Manus has already deployed to the preview URL during the build phase, this play may already be complete. Verify by navigating to the preview URL and confirming the latest QA-passing version is live. If the URL is not live or is showing an older version, ask Manus to redeploy using Wrangler: wrangler pages deploy . --project-name=clientname.

After deployment, verify the preview URL is accessible from outside the Manus sandbox by opening it in a regular browser window (not the Manus browser tool). Confirm all pages load, all images display, and the mobile nav works correctly.

The Review Email

Send the client a short, structured email. Do not write a long email — clients will not read it. The email should contain: the preview URL as a large, obvious link; three specific things to look for (accuracy of business information, completeness of services list, overall visual impression); a clear deadline for feedback (48 hours is standard); and a single sentence explaining the revision process ("We include one round of revisions — please consolidate all feedback into a single list").

Managing Revision Scope

The standard plan includes one round of revisions. A revision round is a single consolidated list of changes — not an ongoing back-and-forth. When the client sends feedback, acknowledge it and confirm which items are in scope. Changes to factual content (wrong phone number, wrong hours) are always in scope. Changes to visual design that were not discussed during the kickoff call are out of scope for the revision round and should be quoted as additional work.

Submitting Revisions to Manus

Paste the client's revision list into Manus as a numbered list. Be specific: "1. Change the phone number in the header from (425) 654-4114 to (425) 654-4144. 2. Add 'Heated Floors' to the services list on the homepage. 3. Replace the hero image with the photo of the marble bathroom I'm uploading now." Upload any new assets before submitting the revision message.

Re-Running QA After Revisions

After Manus applies revisions and redeploys, re-run the axe accessibility audit and the contrast regression check. Client-requested changes — especially color changes, image replacements, and copy additions — can introduce new violations. This step takes 5 minutes and prevents sending the client a revised site with new technical issues.

Before Touching DNS

Confirm the following before making any DNS changes: the client has given explicit approval to go live; the site passes all four audits on the preview URL; you have login access to the client's domain registrar; and the client's existing site (if any) has been backed up or the client has confirmed they do not need the old site preserved.

DNS Configuration Steps

The specific steps depend on whether the client's domain is registered with Cloudflare Registrar or a third-party registrar. For Cloudflare Registrar (preferred): add the custom domain in Cloudflare Pages settings, then add a CNAME record pointing to the Pages URL. SSL is issued automatically within minutes. For third-party registrars: add the custom domain in Cloudflare Pages settings, then update the nameservers at the registrar to point to Cloudflare's nameservers. DNS propagation can take up to 24 hours — warn the client.

Post-Launch Verification

After DNS propagates, verify: the site loads at https://clientdomain.com (with HTTPS, not HTTP); the padlock icon is visible in the browser; all pages load without errors; the contact form submits successfully (test with a real submission); the phone number is a tap-to-call link on mobile; and the Google Maps embed shows the correct location.

UptimeRobot Setup

Log in to UptimeRobot and create a new HTTP(s) monitor for the client's domain. Set the check interval to 5 minutes. Add the Quarterback's email address as an alert contact. Name the monitor "[Client Name] — [Domain]". This takes 3 minutes and ensures the Quarterback is notified immediately if the site goes down.

The Quarterback Briefing

Send the Quarterback a brief internal handoff note containing: the client's name and contact information, the live URL and preview URL, the GitHub repository name, the Cloudflare Pages project name, a summary of any ongoing issues or client preferences noted during the build, and the client's plan level (which determines what maintenance is included). The Quarterback should be able to handle any client request without contacting the Onboarding Specialist.

The Go-Live Email to the Client

Send the client a go-live email from the Quarterback's email address (not the Onboarding Specialist's). This establishes the Quarterback as the primary point of contact going forward. The email should contain: congratulations on the launch, the live URL, the Quarterback's name and contact information, a brief explanation of what to do if they need changes ("Just email me and I'll handle it"), and a request for a Google review.

The Maintenance Request Process

When a client submits a change request, follow this three-step process every time. First, confirm you understand the request by repeating it back to the client in writing: "Just to confirm — you'd like us to update your business hours to show Saturday 9am–2pm instead of 9am–5pm. Is that correct?" This prevents doing the wrong thing. Second, open the client's Manus task (or start a new one), provide the GitHub repository name and Cloudflare Pages project name, and describe the change clearly. Third, after Manus deploys the change, verify it on the live site and send the client a one-sentence confirmation: "Done — your updated hours are now live at [URL]."

Directing Manus for Maintenance Tasks

When starting a maintenance task in Manus, always provide the following context at the start of the message: the client's live URL, the GitHub repository name, the Cloudflare Pages project name, and the specific change requested. Without this context, Manus will spend time trying to find the project files. With this context, Manus can go directly to the relevant file and make the change.

After Every Maintenance Change

After every maintenance deployment, run a quick spot-check: navigate to the affected page on the live site, confirm the change is correct, and confirm no other content was accidentally changed. For changes that touch CSS or colors, run the axe contrast check on the affected page. For changes that add new pages, run the full axe audit on the new page. Do not skip the spot-check — Manus occasionally makes changes to adjacent elements when editing a specific element.

Manus Agent Token

Used to share tasks and collaborate with the Manus AI agent. Provide this token at the start of any Manus session when prompted.

Cloudflare Workers / Pages API Token

Used to interact with the Cloudflare API — checking deployment status, triggering redeployments, and managing Workers and Pages projects.

GitHub Personal Access Token

Used by the Manus agent and local CLI to push code to GitHub repositories under the dotcomdesigniowa organization. Required for all site builds and deployments.

AI Friendliness API Credentials

Used to run unlimited AI Friendliness scans via the scan.aifriendliness.com API. The Agency Unlimited plan removes the 10-scan/day free limit. Manus calls the internal API endpoint directly (POST https://scan.aifriendliness.com/api/analyze-batch/) using these credentials.

How to Provide Tokens to Manus

At the start of a new Manus task that requires API access, paste the relevant tokens into the chat in this format:

Manus Agent: <token>
Edit Cloudflare Workers: <token>
GitHub Token: <token>

Manus will use these tokens for the duration of the session. You do not need to provide all three every time — only the ones relevant to the task at hand.

The Core Problem

Each Manus task runs in an isolated sandbox. A new task has no memory of previous tasks, no knowledge of decisions made in other tasks, and no awareness of standards you have established over time. Without a deliberate system, each agent will make its own decisions about how to build, name, and deploy things — and the results will diverge quickly across clients and agents.

The solution is to make the Playbook the first thing every agent reads at the start of every task. This is not optional. It is the mechanism that ensures consistency regardless of how many agents are running simultaneously.

How to Start Every Task Correctly

At the beginning of any new Manus task, your first message should include three things: the Manus Agent token, the Cloudflare API token, and a reference to the Playbook. The exact format is:

Example opening message: “Manus Agent: [token] — Cloudflare: [token] — Refer to the DD Playbook. Build the website for [Client Name] using the reference site at [URL].”

Both tokens are on the Tokens page.

The Playbook as True North

The Playbook is not a reference document you consult occasionally. It is the operating system for every build. When you encounter a situation where the process feels inefficient, unclear, or broken — the right response is not to improvise. The right response is to finish the task, then come back and update the Playbook so the next agent handles it correctly.

Think of it this way: every lesson learned on a client build is only valuable if it gets written into the Playbook. An insight that stays in your head or in a task thread dies when that task ends. An insight written into the Playbook survives and improves every future build.

Running Multiple Agents Simultaneously

You can run multiple Manus tasks at the same time — one per client, or one per phase of a single client build. Each task is isolated, but they all share the same Playbook. The practical rules are:

Updating the Playbook After a Build

After every client build, spend five minutes asking: what did this build teach us that is not yet in the Playbook? Common candidates include new failure modes discovered during QA, shortcuts that saved time, steps that were unclear and caused confusion, and new tools or CSS patterns that should become standard. Open a new Manus task, reference the Playbook, and say: “Update the Playbook with the following lessons from the [Client] build: [list].” The agent will find the right pages and add the content.