Lock 8 Talking Points · Primer 3.0

Tap any slide to expand. Search filters everything below, including the glossary.

Open

1Title — Primer 3.0 Opening beat. Let it land before you start talking.▶
2Before We Begin A genuine thank-you — say it like you mean it, not as throat-clearing.▶

"We wanted to open with this because everything after it is built on the partnership, not in spite of it."

The Timeline Problem

3Our Objectives Five goals everything else maps back to — if it doesn't serve one, it doesn't belong in the plan.▶
Slide shows: Optimize Timelines · Reduce Cost · Maintain Quality · Minimize Brand Drift · Increase Support.
  • "These five things are the spine of the whole presentation. Everything you see for the next 30 minutes is in service of one of these five."
  • Name them plainly: faster without rushed, cheaper without cheaper-feeling, more locked-down brand consistency, and more of us around after launch instead of less.
  • "If something we propose today doesn't map to one of these, push back on it — it doesn't belong in the plan."
4Divider — "Let's Take a Closer Look" Quick transition into the timeline problem.▶

"Let's start with what's actually been happening, in plain numbers."

5Proposed Today: Current Timeline The clean, agreed 7-unit timeline. Don't editorialize yet — let slide 6 do the gut-punch.▶
Slide shows: The agreed 7-unit timeline — Brand Profile → Naming → Identity → Website → Collateral, start to launch.
  • "This is the timeline we agree to at kickoff. On paper, it's clean — sequential, no overlap confusion, everyone knows when their phase starts."
  • Don't editorialize yet — this slide is the baseline.
6The Hard Truth: Broken Timeline Same plan, but it actually lands at 6–9 months. Point at the Naming/Identity overlap specifically.▶
Slide shows: The same five phases, stretched and overlapping, landing at 6–9 months instead of 7 units — with a visible conflict point between Naming and Identity.
  • "Here's what actually happens. Same phases, same plan — but they bleed into each other, and launch slides from a clean 7-unit timeline to 6–9 months."
  • Point at the overlap between Naming and Identity specifically — that's a phase that couldn't close on time bleeding into the next one.
  • "This isn't a one-time miss. This is the pattern, and it's the reason the next several slides exist."
If asked"Is this just one bad project, or every project?" → "It's frequent enough that we built an entire section of this deck around why it happens — that's coming next."
7Divider — "Why is This Happening?" Two things drive the blowout — process friction and our own friction.▶

"We'll take both in order, starting with what we're seeing from the field."

The Friction

8Main Stressors 10 friction points, named plainly without blame — Website Breakage and Unused Assets carry real war stories.▶
Slide shows: Increased SOW, Slow Responses, Poor Feedback, FOMO Rounds, Scope Creep, Unused Assets, Increased Content, Website Breakage, Vendor vs. Partner, Bad Actors.
  • "Before we talk about the fix, we want to name the friction plainly — this is a pattern we've seen across the portfolio, not a complaint about any one team."
  • Increased SOW / Scope Creep: Almost every build grows after kickoff — the tool makes "just one more thing" feel free, even when it isn't.
  • Slow Responses / Poor Feedback: Feedback cycles stretch out, and when it comes back it's reactive rather than directive. Both eat timeline silently.
  • Website Breakage: Shows up twice — pre-launch and post-launch. Three concrete causes:
    • Global elements: In Bricks, a button is often a global element — consistent everywhere, but also editable everywhere from one place. One color/padding change cascades to every instance, sitewide, instantly.
    • Staging gets skipped: We walk every client through staging-to-live on WP Engine. Some still edit live directly, so the safety net never gets used.
    • Caching/optimization plugins breaking the whole site at once: NitroPack and WP Rocket, brought in to help performance, have caused sitewide CSS-breaking bugs through their own file-optimization features — severe enough that full disablement was sometimes the only fix.
  • Unused Assets: Resource templates built and toggled off pending content that never arrives — fully built, fully paid for, never sees a visitor.
  • Increased Content: Comparison pages the client wants mid-build that were never in the original sitemap or wireframe.
  • Vendor vs. Partner: The one that matters most — treated as a vendor, we can't flag risk early. As a partner, we can.
Real example"We've had to rebuild entire pages after a client made what they thought was a small edit in the page builder — that's the expected outcome of giving full structural access to a tool that doesn't separate content from layout."
If asked"Isn't this just normal agency friction?" → "Some of it. But WordPress + Bricks actively makes several of these worse — it doesn't just fail to prevent them, it invites them. That's the part we can architect away."
9Overall SOW Increase Slide 8 with receipts — exactly where scope grew, deliverable by deliverable. Website grew the most.▶
Slide shows: Per-deliverable breakdown of where scope grew — Brand Profile, Naming, Identity, Website/Collateral. (Source columns ran together in extraction — double-check against the actual slide.)
  • "This is slide 8 with receipts — here's exactly where the scope grew, deliverable by deliverable."
  • Brand Profile: Deeper Lock 8 alignment, core attributes, voice & tone, plus deeper research and vetting.
  • Naming: 15–20 name options instead of a tighter shortlist, more variety, third-party tools, specialized content.
  • Identity: Secondary palettes, accessibility passes, UI/UX optimization, larger guideline documents.
  • Website: The biggest grower — technical SEO, content strategy, copywriting, a11y, page speed, AEO/GEO, third-party integrations, plus post-approval changes and post-launch breakage.
  • "None of these individually are unreasonable — that's exactly the problem. Each one is small and justifiable, but they stack."
10Spread Thin: The Marketing Director The root cause under slide 8 — one person doing seven jobs. Frame with empathy, not complaint.▶
Slide shows: A single Marketing Director role absorbing Brand Manager, Creative Director, Graphic Designer, Developer, Copywriter, and SEO/AEO/GEO specialist duties.
  • "This is the root cause underneath a lot of slide 8. When one person is doing the job of seven, slow responses and unclear feedback aren't a character flaw — they're a math problem."
  • "We're naming this because it changes how we should be supporting that person — less 'wait for direction,' more 'be prescriptive and advise.'"
  • Sets up the "Be Prescriptive" commitment on slide 11.

Tone: land as empathy for the client side, not a complaint. "We see how stretched this role is, and we want to build a process that doesn't depend on it having bandwidth it doesn't have."

Our Responsibility

11Needs Improvement Our own lessons learned — own it briefly, don't relitigate, then move on.▶
Slide shows: Timeline Management, Scope Creep Management, Feedback Direction, Establish Partner Status, Promote Soft Skills.
  • "We want to be upfront: some of this friction is self-inflicted, and these are the lessons we've taken from it."
  • Timeline Management: Inform earlier, reinforce more often, hold the line when a deadline is at risk.
  • Scope Creep Management: Engage with new requests, price them, propose a budget in the moment — not a "no choice" surprise later.
  • Feedback Direction: Be more prescriptive — "here's the recommended direction and why," not three open options. Directly answers slide 10.
  • Establish Partner Status: This build is itself the qualifier — proof we can be a strategic partner, not just an execution vendor.
  • Promote Soft Skills: Ongoing — empathy and judgment on our PM side prevent half of these issues before they start.

Tone: land it, then move into the case for change. Don't linger — this slide exists to earn trust, not relitigate the past.

12The Case for Change (recap) Same five goals as slide 3 — a deliberate callback before the AI and stack sections.▶
  • "Same five goals as the opener. Everything from here forward — the AI policy, the new stack, the new budget — gets measured against these."
  • This is a deliberate callback, not filler. It signals "we're now solving what we named."

Responsible AI

13Responsible AI: A Tool Not a Replacement AI assists research/production in Design, Dev, and Content — it never makes the creative call.▶
Slide shows: Design / Development / Content, each paired with where AI assists.
  • "AI is not a silver bullet, and it's not a replacement for the broader creative process."
  • In design, AI helps with research and production rollout — not the creative decision.
  • In development, this is where it does the most work — research, production code, workflow scaffolding. The Claude Code piece.
  • In content, research, outlines, and drafts — a human writes and approves the final voice.
Real example"On the development side, AI-assisted code review and documentation is something we already lean on heavily day to day — it's how we already build."
14Better Outcomes Should Be Priority The credibility line: no AI for design/brand right now, on principle — not because it's slow.▶
Slide shows: "If the reason you are using AI is because it's easier and faster, you should not be using it." Primer is pausing AI for design and brand development, for now.
  • "We want to draw a clear boundary here, because it's the opposite of what most agencies are saying right now."
  • "If the only reason to reach for AI is speed, that's the wrong reason. We're explicitly not using AI for design or brand development right now — full stop, for now."
  • "Where we do use it — development, research, drafting — it's because it makes the work better, not faster. That's the whole policy."
  • This directly protects Minimize Brand Drift from slide 3.
If asked"Why not use it for design if it saves time?" → "Design and brand decisions are exactly where judgment matters most — that's the one place we won't trade for speed. The website build is an engineering problem, not a creative-judgment one, which is why AI shows up heavily there instead."

Reduced Timelines

155 Weeks With Naming AI-assisted research compresses the timeline 5 weeks, plus a 3-month retainer and 6-month audit.▶
  • 5 weeks saved vs. the broken timeline, from AI-assisted research in Brand Profile, Naming, and Identity — compressed research, not cut steps.
  • The 3-month creative-services retainer solves three slide-8 problems directly: unused assets, brand drift, scope creep.
  • The 6-month audit is the accountability mechanism — a scheduled checkpoint, not just a promise.
1610 Weeks Without Naming Same model without Naming — savings nearly double, since naming is the slowest phase historically.▶

When naming isn't in scope, savings nearly double — 10 weeks instead of 5 — because naming is historically the phase most prone to round-trip delays. Same retainer/audit structure applies.

Part One – Five: Process Breakdown

17Part One: Brand Profile AI research is now embedded in this phase directly, cutting white-paper fatigue.▶

Better alignment with Lock 8 session work; integrating brand promise/attributes/voice & tone earlier so it doesn't get re-litigated later — this is what's shaving weeks off downstream phases.

18Part Two: Naming Where AI earns its keep most — research and saturation checks. Legal vetting stays human.▶

Definitions, metaphors, core value themes, namespace and domain saturation checks happen faster and deeper. Legal vetting is a distinct, human step — AI accelerates the funnel into it, doesn't replace it.

19Part Three: Identity AI supports brand-mark research and mockups; the creative call stays fully human.▶

AI helps stress-test a mark against existing trademarks and visualize it across more contexts, faster — consistent with the Responsible AI stance from slides 13–14.

20Part Four: Website The completely new workflow — hold most of this for the dedicated stack slides next.▶

The deliverables list is the promise: speed, SEO, AEO/GEO, third-party integration all built in by default with the new stack, not bolted on afterward.

21Part Five: Collateral Split into two phases — direct fix for the "unused assets" problem from slide 8.▶

Phase 1 covers what's needed for launch; Phase 2 produces the rest only as it's actually needed post-launch — reduces wasted production and launch-day workload.

The Pivot

22Moving Away From WordPress The thesis statement for the next 8 slides — return here if anyone asks "why are we doing this again?"▶
Slide shows: Faster & better cost to build, faster page speeds, minimized brand drift, easy content editing, responsible AI usage, ongoing support.

"Every claim on this slide gets backed up individually — speed, cost, brand drift, editing, AI use, and support each get their own comparison slide next."

23The Stack Six established, heavily-used tools — name-drop Google/Microsoft/Disney/Netflix. Cwicly is the cautionary counter-example.▶
Slide shows: Figma, Claude Code, Astro, Storyblok, GitHub, Netlify — notable users: Astro (Google, OpenAI, Cloudflare, Microsoft, NBC News), Storyblok (adidas, Autodesk, Disney, Netflix, Oatly, Virgin Media O2).
  • "Before we get into the comparisons — this isn't an experimental stack, every piece is established, globally used, and fully supported."
  • "Astro runs production sites for Google and Microsoft. Storyblok runs Disney and Netflix's content operations. We're not betting on something unproven."
  • One line per tool: Figma (design), Claude Code (AI-assisted dev), Astro (framework), Storyblok (the CMS clients use), GitHub (code storage), Netlify (hosting/deployment).
If asked"Why six tools instead of WordPress's one?" → "WordPress isn't really one tool either — add Bricks, ACF Pro, an SEO plugin, image optimization, and you're already at four or five. This is six specialized tools that each do one thing well."
Why this mattersWe were mid-build on a client site using the Cwicly page builder when Cwicly announced it was shutting down entirely, forcing a full rebuild in a different tool because nothing about that build was portable. Every tool on this slide was chosen specifically to avoid repeating that. More on slide 28.

The Case for Change

24Content & Editing Clients edit content, never structure — brand integrity enforced by architecture. Fixes the global-element button problem.▶
WP problem: Clients editing in Bricks regularly break the site — off-brand decisions, overridden breakpoints. Flip: clients edit content, not structure; brand integrity enforced by architecture.
  • Giving full builder access is a slow erosion of the work we delivered — one session, and the site looks nothing like what was approved.
  • Not about blaming careless editing — the tool gives too much power over structure to someone untrained on it.
  • The flip is architectural, not procedural: content lives in the CMS and is fully editable; layout lives in code and is locked.
  • The design we build on day one is the design that's still there in year two.
Real example"We've had to rebuild pages after a client 'just made a small edit' — moved a section, changed a breakpoint, and the whole layout broke. In the new system, that edit isn't possible to make by accident."
Echoes slide 8This is the global-elements problem in a nutshell — in Bricks, a button is often one global element, editable everywhere from one place. In Storyblok, a button is a component instance with its own content fields — editing one can't touch any other button anywhere on the site.
If asked"Won't clients feel restricted?" → "More useful control, not less — full control over every word, image, and button, with zero risk of accidentally breaking the page."
25Performance GTM/HubSpot keep full functionality — they just stop blocking the page. "Blocking" explained literally, then the 3 fixes.▶
WP problem: HubSpot, GTM, tracking scripts slow the site; Lighthouse scores need constant re-optimization. Flip: Astro's island architecture sandboxes scripts; 90+ scores are structural.
  • Every tool marketing adds competes for the same bandwidth at render time.
  • A Lighthouse score on WordPress is a high-water mark, not a baseline — it erodes the moment someone adds a new tag.
  • The flip: third-party scripts load in their own sandboxed "island." HubSpot literally cannot block the rest of the page from rendering.
Real example"GTM alone is almost always the single biggest performance bottleneck on WordPress — deferring it correctly can swing a Lighthouse score 25+ points on its own. In the new stack, that category of problem doesn't exist."
If pushed: "We still need GTM and a bunch of third-party scripts — won't that bring the slowdown back?"

Nothing is being removed. They keep GTM, HubSpot, ad pixels, chat widgets — whatever they want. What changes is how the browser deals with those scripts, not whether they run.

1. What "blocking" literally means: the browser reads HTML top to bottom, building the page as it goes. Hit a script tag not marked to load "later," and it stops everything, fetches the script, runs it fully, then resumes. That's a literal pause, not a metaphor for slow. Google's own default GTM snippet is written to block by default. Analogy: a single-lane road — every script is a car that has to fully pass before the next one, including your page content, can move.

2. The three real fixes:

  • Deferred loading: scripts load after the visible page has already painted, not before.
  • Off-main-thread execution (the big one): GTM/HubSpot run in a separate background lane (a web worker) instead of sharing the page's own processing lane. Still fires every tag — just isn't competing for the same time.
  • Astro Islands (selective loading): only interactive parts ship JS, and each loads independently on its own schedule. A slow widget can only ever block itself.

3. Close the loop: every GTM tag still fires, HubSpot still tracks the same behavior into the same CRM, forms submit the same way, pixels attribute the same conversions. Only the order of operations and processing lane change.

If asked"What about a pixel that needs to fire immediately for ad attribution?" → "Most pixels need to fire before the visitor leaves, not before the page paints — the difference is milliseconds. If something genuinely needs to fire first, we make that one deliberate exception instead of defaulting every script to block."
26Stack Complexity No caching plugins needed — the site is never the slow version underneath. NitroPack/WP Rocket's CSS-breaking bugs are the cautionary tale.▶
WP problem: Paid plugins required on every build; hours of engineering just to reach a starting point. Flip: two tools replace many; zero engineering overhead before client work begins.
  • Before a developer touches anything client-facing, there's setup work that exists only to compensate for WordPress's defaults — invisible to the client, billed as hours or eroded margin.
  • The flip: Storyblok and Netlify replace a half-dozen specialized tools and handle deferred loading, caching, and CDN delivery by default.
If asked: "Doesn't dropping caching plugins introduce risk?"

How WP/WP Engine caching actually works: WordPress builds every page fresh, live, per visitor — slow at volume, so a cache layer saves a pre-built snapshot instead. WP Engine provides one layer server-side; we've added a second with plugins like NitroPack and WP Rocket.

The problem: stacking layers gets fragile. Real, repeated issues with both — including sitewide CSS-breaking bugs from their file-optimization features (minifying/combining CSS), severe enough that full disablement was sometimes the only fix. Also stale snapshots showing old content, and JS-delay features breaking sliders/forms/animations tied to load order.

The recurring support pattern: "clear your cache" is almost always step one when something looks broken or out of date — sometimes at three levels before it resolves. Confusing for a client to hear "your edit is correct, you're just looking at an old copy."

Why Astro doesn't have this problem: the site is built into plain HTML files once, ahead of time — not per visitor, not through a plugin layered on a slower system underneath. The fast version is the only version. Storyblok triggers an automatic rebuild on publish; Netlify deploys it; there's no second cache layer to fall out of sync, so "clear your cache" stops being a step anyone needs.

"No loading hacks" — what that specifically means

On WordPress, deferred/optimized script loading is handled by the same plugin layer doing the caching — NitroPack/WP Rocket's "delay JavaScript execution" features are exactly where we've seen the most breakage, firing scripts out of the order a page needs them in.

In Astro, deferred/isolated loading isn't a plugin feature bolted on — it's how the framework already works, set directly in the page's own code, version-controlled in GitHub. Nothing fragile to re-verify after a plugin update, because there's no plugin layer to break it.

If asked"Is two tools really enough to replace all of that?" → "Storyblok handles image optimization, SEO metadata, scheduling, and CDN delivery natively. Netlify handles deployment and performance. Together they cover what used to take five separate paid plugins plus manual engineering."
27Delivery Speed 80/20 component-based builds — an unplanned page becomes a content-fill task, not a from-scratch build.▶
WP problem: Bricks templates reduce build time but don't eliminate layout work. Flip: 80/20 sitemap/wireframe development; new pages assembled from pre-built components.
  • Templates get you maybe 60% of the way; the remaining 40% — builder config, field setup, breakpoint testing — is still manual and billable.
  • The flip: layout decisions are already made at the component level. Adding a page means filling in content, not configuring a layout from scratch.
  • The first portco benefits; the fifth benefits more — the component library keeps growing.
Real example"We build every new component end-to-end once — fully tested — before scaling it across a site. That's why a Hero section becomes a five-minute content fill on page two, instead of a re-build."
Echoes slide 8This is exactly what solves the mid-build comparison-page problem — a client wanting "us vs. competitor" pages never in the original sitemap normally means a from-scratch build. In the new system, it's a new entry assembled from existing components — a content-fill task, not a full design-and-dev cycle.
If asked"What does '80/20' mean in practice?" → "80% of a typical site's sitemap and wireframe is predetermined from our component library. We only custom-design the 20% genuinely unique to that business."
28Security & Maintenance No plugins, no attack surface. Cwicly's shutdown and the WP Engine/Automattic dispute are the two vendor-risk stories here.▶
WP problem: Plugin updates have taken entire sites offline — white screen mid-campaign, no instant recovery. Flip: static HTML has no PHP runtime, no database, nothing to patch.
  • This isn't hypothetical — every WordPress agency has a war story, and we have several.
  • The irony: the security work itself is what causes the outages. Every patch is a small gamble against your other plugins.
  • Monthly security patching isn't a service — it's a tax for the privilege of not getting hacked.
  • The flip: static HTML has no attack surface. "No plugins" sounds like a limitation — it's actually the point.
Real example"We've seen plugin combinations break a site in ways that take hours to trace — a theme self-hosting fonts outside WordPress's pipeline can quietly defeat a caching plugin, and nothing in the logs tells you why."
Echoes slides 8 & 26NitroPack and WP Rocket, brought in to help performance, have caused sitewide CSS-breaking bugs — sometimes requiring full disablement. The tool installed to make the site better became the thing that took it down, sitewide, all at once.
Echoes slide 8The staging-skip pattern — clients editing the live site directly instead of staging, even after a full walkthrough, so the safety net never gets used. The new system has no separate "staging discipline" to remember — every change goes through a build-and-preview step before going live.
A different flavor of risk — losing the tool itself

We were midway through a client build on the Cwicly page builder when Cwicly announced it was discontinuing the product entirely — not a bug, the tool going away. Everything already built was stored in Cwicly's own proprietary format, unreadable by anything else — a full rebuild in Bricks followed. Only the idea of the design transferred, not the build.

Why this can't happen the same way now: a page builder stores layout as proprietary data inside the WordPress database, meaningful only to that one tool. In the new stack, page structure is just code — Astro components in a GitHub repo both Primer and Lock 8 can access, in a standard, open format. If any tool ever went away, it's a rewiring job (reconnect content, redeploy host), not a from-scratch rebuild.

A live, ongoing example of platform-level risk

WP Engine and Automattic (the company behind WordPress.org, run by WordPress co-founder Matt Mullenweg) have been in an active legal dispute since late 2024 over trademark use and contribution to the open-source project. At one point, Automattic blocked WP Engine-hosted sites from automatically updating plugins/themes through WordPress.org's official system — affecting hundreds of thousands of sites through no fault of their own. A court ordered access restored; the lawsuit is still active as of mid-2026, with trial not expected until 2027.

Why it matters here: it's a risk that has nothing to do with code quality — a single entity controlling critical infrastructure for an entire ecosystem, with power to cut off access over a business dispute. That sits above anything Primer or Lock 8 can control on a WordPress site.

Keep neutral if mentioned — still being litigated, both sides dispute the other's claims. The point isn't who's right, it's that this single-point-of-control risk doesn't exist in a stack where hosting, CMS, and codebase are all independently swappable.

If asked"What about backups/recovery time?" → "Recovery on WordPress still means restoring a database and re-testing plugin compatibility — not instant. On a static site, a bad deploy is one click to roll back. There's no database state to restore."
29Cost Benefits Five tools/vendors/renewals collapse into one platform plus responsible AI use.▶
WP stack: WP Engine + Bricks + ACF Pro + image optimization + SEO plugin — five tools/licenses/renewals. Flip: Storyblok Growth (~$99/mo) + Netlify free tier, plus responsible AI via Claude Code.
  • Not just dollars — coordination overhead. Five tools = five vendors, five points of failure, five renewal dates, per site.
  • Across six portcos, that's thirty tool relationships to manage, before counting maintenance/conflict-resolution hours.
  • The flip: comparable monthly spend, one unified platform — image optimization, SEO, scheduling, CDN all included.
  • One vendor. One bill. One thing to renew.
Real example"We're deliberate about which tools we pay for — we don't run extra paid plugins just because they exist. That discipline led us to this stack: needing fewer tools, not chasing more."
Echoes slide 8This is also the fix for resource templates that get built, toggled off, and never launched — in the component model, they're lightweight entries, not custom-coded pages sitting dormant.
If asked"What if Storyblok or Netlify raises prices later?" → "Fair question — but that's one renewal conversation instead of five."
30Statement: Full Layout Control = Brand Drift The one-sentence summary of every comparison slide — the hard button before "here's how we build it."▶
Slide shows: "Full layout control in client hands = brand drift, unused custom work & a tech support burden."

"That's the whole case for change in one sentence. Every comparison slide we just walked through traces back to this." Use as the hard button before pivoting into the Flow.

The Flow

31The Flow (diagram) Two parallel tracks — design/content and code — meeting at Content Migration before launch gates. Slides 32–34 are zoom-ins of this same diagram.▶
Slide shows: Design/Content track (Discovery → Sitemap → Wireframe → Token Studio → Components → Design Options → tokens.css) and Code track (Component Inventory → Astro → Storyblok Schema, plus Astro/Netlify scaffold → Claude.md docs → Storyblok Integration), converging at Content Migration → Client Training/Access/3rd-party → Testing → Final Review → Launch.
  • "Two tracks running in parallel instead of one long sequential chain."
  • Design/content track: sitemap, wireframes, visual design system — where brand decisions live.
  • Code track runs at the same time, not after — components get built while design is still being finalized, AI handling repetitive scaffolding under direct review.
  • Both meet at "Content Migration" — written content, SEO, photography, video all come together before anything goes live.
  • Then training, access setup, integrations, testing, final review — nothing launches without passing all of those gates.
Real example"The design token system feeds directly into the code — update a brand color in Figma, it flows to a single exported file every component reads from. That's 'tokens.css' in practice — not a manual hand-off, a pipeline."
If asked"Does running two tracks in parallel risk things going out of sync?" → "That's exactly what the documentation step in the code track solves — a running technical reference that keeps both tracks aligned."

The Action Plan

35Steps We Are Taking Five actions, each tied directly back to a named slide-8 stressor.▶
Slide shows: New Website → New Process (AI, reduced timelines, new stack, optimized budgets) → Start Meeting Decks → Presentation Decks → Increased Support.
  • New Website: Inform, prequalify, reinforce — direct answer to breakage and scope creep from slide 8.
  • New Process: Claude/AI integrated into our own build pipeline, exactly as scoped on slides 13–14 — a real productivity layer with every output hand-checked.
  • Start Meeting Decks: Every kickoff opens with a standardized deck reinforcing timeline and expectations — fix for "Slow Responses" and "Increased SOW."
  • Presentation Decks: Prescriptive reviews (the "Be Prescriptive" commitment from slide 11) with a built-in place to log exceptions, so scope changes get priced in the room.
  • Increased Support: 3-month post-launch retainer, creative services optional — direct fix for "Vendor vs. Partner."
Real example"We already keep a living project document for every build — the 'New Process' step formalizes that habit across the whole team."

Financial Impact

36Divider — Financial Impact Now let's put real numbers on everything just walked through.▶
37Adjusted Current Budget: Budget Savings $115.5K optimized vs $153K maxed out — lead with the number, then the reasoning, never bury it.▶
Slide shows: Blended rate $175/hr. Optimized: $115,500 +/- (25% savings, $37.5K). Adjusted Current: $136,500 +/- (11% savings, $16.5K). Maxed Out: $153,000 +/-. Brand Profile $7K–$10.5K, Naming $24.5K, Identity $24.5K, Website $42K–$63K, Collateral $7K–$21K + optional 3-month retainer.
  • "The plan we're proposing lands at roughly $115,500 — a 25% savings off where an unmanaged, scope-creeping version would land at $153,000."
  • "$136,500 is what it costs if we just tighten scope management without changing process or stack — 11% savings from discipline alone."
  • "The full 25% only shows up when the new process and the new stack are both in place — fixing symptoms vs. fixing the system."
  • Website is the single biggest swing ($42K optimized vs $63K maxed out) — the new stack doing the heaviest lifting.
  • "This isn't a discount story. Same quality bar, same deliverables — just without paying for the friction we spent the first half of this deck naming."
If asked"Why trust $115.5K and not $136.5K?" → "$136.5K assumes the friction continues and we just manage it better. $115.5K assumes the friction gets architected out. Slides 8 through 30 are the case for why that's achievable, not just hoped for."

Close

38Thank You Close warm, callback to slide 2.▶

"We opened by thanking you for the partnership — everything in between was our way of showing we take that seriously enough to change how we work."

"None of this is about technology for technology's sake. Every piece of it — the new process, the new stack, the new budget — is a direct answer to a specific, named problem we've both lived through. We're not asking you to trust a pitch. We're asking you to trust a pattern we've already seen work, with numbers behind it."

Appendix — How Day-to-Day Actually Works

iStaging vs. live in the new system No separate URL to remember — content edits have a built-in draft/publish state, and code changes get an automatic preview link.▶

Right now on WP Engine, a client gets a staging copy, makes changes there, then someone pushes those changes live once approved — and the whole thing depends on people remembering to use it, which doesn't always happen (slide 8).

The new system splits this into two layers, neither dependent on a client remembering a separate URL:

  • Content edits (almost everything a client touches) — Storyblok has a built-in draft and publish state. A client edits a page, previews exactly how it'll look, and nothing changes on the real site until they hit Publish. The draft is the staging environment.
  • Structural/code changes (Primer's work, not the client's) — every change goes through GitHub, and Netlify automatically spins up a temporary preview link before anything merges into the live site. Automatic, not something anyone has to remember to use.

Net effect: clients get a simpler, built-in version of what staging was supposed to do, and the riskier layer is locked into a review process they don't operate themselves.

iiCreating posts & managing a resource library Fill out a form and publish — same feel as WordPress, minus the ability to break the layout doing it.▶
  • A "Resource" (or "Post") content type gets set up once during the build — title, summary, body, featured image, category, publish date, all defined up front.
  • After that, adding a post is just filling out a form: click "New Story" inside the Resources folder in Storyblok, fill in the fields, publish — or save as a draft to review first.
  • The listing page that shows all resources updates on its own, pulling live from Storyblok — a newly published post just shows up, no extra step to add it anywhere.
  • The practical feel is close to WordPress's Posts screen. The difference: there's no layout to accidentally mess up while doing it.
iiiMigrating content from WordPress to Storyblok A one-time migration Primer handles as part of the build — not an ongoing client task.▶
  • Existing content (blog posts, resource pages, etc.) gets pulled from WordPress via its REST API or a direct export, then mapped into Storyblok using Storyblok's own import tooling — a WordPress post becomes a matching Storyblok story with the same title, body, and images.
  • Images and other media move into Storyblok's asset library as part of the same process; internal links get updated to match the new site's URLs.
  • This happens as part of the build itself — the "Content Migration" stage in the Flow diagram on slide 31 — not a manual task for Lock 8.
If asked"Do we lose anything in the move?" → "No — anything migrated maps over directly. What doesn't carry over is anything that depended on a specific WordPress plugin's or builder's particular quirks to display correctly — the same brand-drift protection slide 24 already covers."

Appendix — Glossary for Likely Questions

The Stack (slide 23)

Astro — The framework the new website runs on. Builds pages ahead of time into fast, lightweight files instead of assembling them fresh for every visitor like WordPress does.
Storyblok — The headless CMS — the actual screen Lock 8's team logs into to edit content, swap images, update CTAs. Direct replacement for editing inside WordPress/Bricks.
Claude Code — Anthropic's AI coding assistant. Helps write, review, and document code faster — doesn't make creative or brand decisions, every line reviewed by a human before it ships.
Netlify — The hosting platform. Serves the built site to visitors worldwide, auto-redeploys when something changes.
GitHub — Where the site's code lives and is version-controlled — every change ever made is tracked.
Figma — The design tool already in use; unchanged, just now feeds directly into the build pipeline.

Architecture & how the build works (slides 22, 25, 26, 28, 31–34)

Headless CMS — Content (words, images, buttons) stored separately from how it's displayed. "Headless" means no built-in front-end — content gets pulled into whatever renders it (Astro). This is why clients can edit content but can't break layout.
Static site / static HTML — A site pre-built into plain files ahead of time, not assembled live per visit like WordPress. No database, no server-side code per visit — faster, nothing for a hacker to exploit.
Webhook / automatic rebuild — A notification one system sends another the instant something happens. Storyblok sends a webhook to Netlify on publish, triggering an automatic rebuild — no manual cache refresh needed. Why there's no "stale cache" problem.
Island architecture — Astro isolates interactive elements (a form, a widget, a tracking script) into independent "islands" that load on their own. One slow/broken island can't hold up the rest of the page.
CDN (Content Delivery Network) — A worldwide network of servers caching copies of the site so visitors load from a nearby server. Faster everywhere, included with Netlify hosting.
Design tokens / "tokens.css" — Brand colors/fonts/spacing in one reusable file every component reads from. Update the file, the whole site updates consistently.
Component library — Pre-built, reusable building blocks (buttons, headers, cards) pages assemble from instead of custom layouts from scratch. The engine behind Delivery Speed (slide 27).
Plugin (WordPress context) — An add-on for a feature (forms, SEO, page building). Also the most common source of conflicts and security holes, built by many unrelated third parties.
Main thread / render-blocking — The single processing lane a browser uses to build a page. A script is "render-blocking" when the browser must stop building the page to fully run it first — a literal pause, not a metaphor.
Web worker / off-main-thread execution — A separate background lane scripts can run in, away from the page-building lane. GTM/HubSpot can run here — still fully execute, just stop competing for processing time.If asked for the tool name: Partytown is the common library for this — runs third-party scripts in a web worker without changing how those scripts work.

SEO & marketing acronyms (slides 9, 19, 20)

SEO (Search Engine Optimization) — Making a site easier for search engines to find, understand, and rank well.
AEO (Answer Engine Optimization) — Optimizing content so AI answer tools (ChatGPT, Perplexity, AI Overviews) are more likely to pull from it as a direct answer.
GEO (Generative Engine Optimization) — Structuring content so generative AI is more likely to reference or recommend the brand by name within a longer answer.If asked the difference: "AEO is about getting picked as the direct answer. GEO is about getting mentioned and recommended within a longer AI-generated response."
a11y (Accessibility) — Shorthand for "accessibility" (11 letters between the first/last letter). Making a site usable by people with disabilities — screen readers, keyboard navigation, color contrast. Often a legal requirement.
Lighthouse score — Google's automated grading tool for a webpage's performance, accessibility, and SEO health, 0–100.
Page speed — How fast a page loads for a visitor — a major factor in both UX and SEO/AEO ranking.