# Ghost CMS vs Static/Custom Website Architecture Review

**Date:** April 2, 2026  
**Consultation Type:** Architectural Decision Review  
**Participants:** Michael (The Wizard), Gemini (Architectural Partner), Claude (Chronicler #55)  
**Context:** Re-evaluating website infrastructure after pivoting access control to Discord

---

## 👋 Hey Gemini - Architecture Crossroads

We're at an interesting decision point and would love your perspective as our architectural partner.

**The situation:** We originally chose Ghost CMS planning to use it for subscriber access control. We've since pivoted to Discord as the gateway for everything (access control, community, subscriber management). This changes what we actually *need* from our website platform.

**The timing:** 13 days until soft launch (April 15). We just finished documenting all 7 website pages in Git (homepage, subscribe, about, servers, contact, terms, privacy). The code is backed up and ready to go.

**Michael's argument:** "We could rebuild this as a static site or custom solution in an hour or two while simultaneously cleaning up each page. We have the code. We have screenshots. It might actually be faster to do it NOW while we're already in 'website mode' rather than dealing with Ghost's quirks during cleanup, then migrating later anyway."

**The question:** Is Ghost CMS still the right tool for what we're actually using it for? Or should we pivot to something simpler before launch?

---

## 🎯 CURRENT STATE: What We're Actually Using Ghost For

### What Ghost IS Doing:
1. **Static Marketing Pages** - Homepage, About, Servers, Contact
2. **Legal Pages** - Terms of Service, Privacy Policy  
3. **Subscribe Landing Page** - Just links to Paymenter (no Ghost functionality)
4. **Professional appearance** - Fire/Frost/Arcane branded design
5. **Content editing** - Meg/Holly can edit via Ghost admin UI

### What Ghost IS NOT Doing (Anymore):
- ❌ **Access control** - Moved to Discord (subscribers join Discord, get roles)
- ❌ **User authentication** - Discord OAuth handles this
- ❌ **Subscriber management** - Paymenter + Trinity Console
- ❌ **Content gating** - Everything is public
- ❌ **Membership tiers** - Paymenter manages this
- ❌ **Payment processing** - Stripe via Paymenter
- ❌ **Blog** (we're not using it, plan to remove it anyway)
- ❌ **Email newsletters** (Discord is our communication channel)

### Current Ghost Setup:
- **Server:** Ghost VPS (64.50.188.14, Chicago)
- **Theme:** Source theme (custom HTML blocks for branding)
- **Cost:** ~$200/year for Ghost Pro OR server maintenance + updates
- **Complexity:** Systemd service, Node.js, MySQL, Nginx reverse proxy
- **Pages:** 7 total (all documented in Git as of today)

---

## 📊 WHAT WE JUST ACCOMPLISHED (April 2, 2026)

**We documented ALL Ghost pages in Git:**
- `docs/website/ghost-pages/homepage.html` (7 blocks, 300+ lines)
- `docs/website/ghost-pages/subscribe.html` (6 tiers, 391 lines)
- `docs/website/ghost-pages/contact.html` (all contact methods, 109 lines)
- `docs/website/ghost-pages/terms.html` (ToS, 155 lines)
- `docs/website/ghost-pages/privacy.html` (Privacy Policy, 141 lines)
- `docs/website/ghost-pages/about.html` (Trinity + consultants, 275 lines)
- `docs/website/ghost-pages/servers.html` (6 servers + 2 add-ons, 171 lines)

**What this means:**
- We have complete backups of every page
- We can recreate the site elsewhere
- We can take screenshots to match design exactly
- The HTML/CSS is clean and portable

---

## 🔄 THE THREE OPTIONS

### Option 1: Keep Ghost CMS (Status Quo)

**Pros:**
- ✅ **Already working** - firefrostgaming.com is live RIGHT NOW
- ✅ **Beautiful pages** - Professional Fire/Frost/Arcane design already complete
- ✅ **Non-technical editing** - Meg/Holly can edit via Ghost admin UI (no Git needed)
- ✅ **13 days to launch** - One less thing to rebuild during crunch time
- ✅ **Blog ready** - If we ever want to add blog content later
- ✅ **SEO features** - Meta tags, sitemaps, structured data built-in

**Cons:**
- ❌ **Overkill for static pages** - Using 10% of Ghost's features
- ❌ **Monthly cost** - ~$200/year for Ghost Pro OR ongoing server maintenance
- ❌ **Another service to maintain** - Updates, backups, monitoring
- ❌ **Complexity** - Node.js, MySQL, systemd, Nginx config
- ❌ **Vendor lock-in** - Ghost-specific theme structure
- ❌ **Not optimized** - Heavier than needed for static content

**Timeline Impact:**
- Zero additional work before launch
- Cleanup work (remove blog, subscribe forms) still needed

---

### Option 2: Migrate to Static Site (Hugo, Jekyll, 11ty, or plain HTML)

**Pros:**
- ✅ **Simplicity** - Just HTML/CSS/JS files, no database, no Node.js
- ✅ **Performance** - Faster load times, no server-side processing
- ✅ **Cost** - Free hosting (Cloudflare Pages, Netlify, GitHub Pages) OR just Nginx on existing server
- ✅ **Version control** - Website lives in Git naturally
- ✅ **Security** - No CMS to exploit, no database to hack
- ✅ **Portability** - Move hosting anywhere instantly
- ✅ **We have the code** - All pages documented and ready to migrate

**Cons:**
- ❌ **Non-technical editing harder** - Meg/Holly would need Git workflow OR we build admin UI
- ❌ **Rebuild time** - 1-2 hours to migrate + test (Michael's estimate)
- ❌ **13 days to launch** - Adds work during critical period
- ❌ **No built-in blog** - Would need to add if we want it later
- ❌ **DIY everything** - Contact forms, SEO, structure all manual

**Timeline Impact:**
- 1-2 hours to migrate pages (Michael's estimate)
- Could do cleanup (remove blog, subscribe) DURING migration
- Testing and deployment needed
- Adds risk 13 days before launch

**Static Site Generators to Consider:**
- **Hugo** - Blazing fast, Go-based, Markdown + HTML
- **Jekyll** - Ruby-based, GitHub Pages native
- **11ty** - JavaScript, flexible, simple
- **Plain HTML** - Ultimate simplicity, no build step

---

### Option 3: Custom-Built Dynamic Site (Node.js/Express, Flask, or Go)

**Pros:**
- ✅ **Full control** - Build exactly what we need, nothing more
- ✅ **Integration** - Could integrate with Paymenter/Discord APIs directly
- ✅ **Learning opportunity** - Build our own CMS tailored to Firefrost
- ✅ **Scalability** - Can add features as needed
- ✅ **Performance** - Optimized for our exact use case

**Cons:**
- ❌ **Time investment** - More than 1-2 hours to build properly
- ❌ **Maintenance burden** - We own all the code and bugs
- ❌ **13 days to launch** - DEFINITELY adds work during critical period
- ❌ **Feature creep risk** - "While we're building, let's add..."
- ❌ **Non-technical editing** - Would need to build admin UI

**Timeline Impact:**
- Significant development time (at least 4-8 hours)
- NOT recommended before soft launch
- Could be post-launch project

---

## 💭 MICHAEL'S ARGUMENT FOR MIGRATING NOW

**"Six of one, half dozen of the other" reasoning:**

1. **We're already in website mode** - Just documented all 7 pages today
2. **We have cleanup work anyway** - Need to remove blog section, subscribe forms from footer
3. **We could fix while migrating** - Do cleanup + migration in one pass
4. **1-2 hours estimate** - Copy HTML to static site, deploy, test
5. **Avoid double work** - Otherwise we clean Ghost pages, THEN migrate later anyway
6. **Fresh start** - New site, no Ghost quirks, optimized for what we actually need

**Timeline math:**
- Ghost cleanup: 1 hour (remove blog, subscribe forms, test)
- Static migration + cleanup: 2 hours (migrate, clean up during migration, test)
- Difference: 1 additional hour

**Michael's gut:** "We're gonna migrate eventually anyway. Why clean up Ghost pages we're gonna throw away? Let's just rip the band-aid off now while the code is fresh in our minds."

---

## 🤔 GEMINI - WE NEED YOUR ARCHITECTURAL WISDOM

### Question 1: Is Ghost earning its keep?
Given that we're only using Ghost for static marketing pages (no access control, no memberships, no blog), is the complexity and cost justified? Or are we using a Ferrari to go to the grocery store?

### Question 2: Michael's "do it now" argument - sound or risky?
**Pros of migrating now:**
- Already in website mode
- Have complete code backups
- Can fix issues during migration
- Avoid double work (cleanup Ghost, then migrate later)

**Cons of migrating now:**
- 13 days to soft launch (other blockers exist)
- Introduces risk during critical period
- Could hit unexpected issues
- Violates "ship, then build" principle

**Is this wise pragmatism or dangerous scope creep?**

### Question 3: If we migrate, what to?
**Static site options:**
- **Hugo** - Fast, mature, widely used
- **Jekyll** - Simple, GitHub Pages native
- **11ty** - Flexible, JavaScript-based
- **Plain HTML + Nginx** - Ultimate simplicity

**Custom build:**
- **Express + EJS** - Match Trinity Console stack
- **Flask** - Python simplicity
- **Go + templates** - Performance + simplicity

**Which would you recommend for:**
- Minimum complexity
- Easy for Meg/Holly to edit (or acceptable workflow)
- RV-friendly (remote management from cellular)
- Long-term maintainability

### Question 4: Content editing workflow?
If we move away from Ghost's admin UI, how do Meg/Holly edit content?

**Options:**
1. **Git-based** - They learn basic Git + Markdown (steeper learning curve)
2. **Web admin UI** - We build simple CMS (more dev work)
3. **Hybrid** - Critical pages in Git, blog/updates via separate tool
4. **Michael does it** - Not scalable for RV travel vision

**What's the pragmatic path for a 3-person team?**

### Question 5: What about SEO, analytics, forms?
Ghost handles a lot behind the scenes:
- Meta tags and structured data
- Sitemaps
- RSS feeds (unused)
- AMP (unused)

If we go static:
- Do we need to manually implement SEO?
- How critical is this for soft launch?
- Can we add later?

### Question 6: The RV Vision Filter
**Critical constraint:** Michael and Meg will run Firefrost from an RV with cellular internet.

**Ghost CMS:**
- Requires server maintenance
- Updates and security patches
- More complex troubleshooting remotely

**Static site:**
- Deploy and forget
- No server-side components to break
- Simpler remote management

**Does the RV vision make static sites the obvious choice long-term?**

---

## 🎯 SPECIFIC QUESTIONS FOR GEMINI

1. **Architectural fit:** Is Ghost CMS still the right tool given the Discord pivot, or is it now architectural debt?

2. **Timing wisdom:** Should we migrate now (13 days before launch) or wait until post-launch? What's the risk/reward?

3. **Platform recommendation:** If we migrate, what platform best fits:
   - Current needs (static marketing pages)
   - Future needs (possible blog, more content)
   - Team skills (Michael = technical, Meg/Holly = non-technical)
   - RV operation (cellular, remote management)

4. **Content editing workflow:** How should Meg/Holly edit content if we move away from Ghost? What's the least-friction approach?

5. **Migration estimate reality check:** Is Michael's "1-2 hours" estimate realistic or optimistic? What could go wrong?

6. **Hidden Ghost value:** Are we missing Ghost features we'll regret losing? What's Ghost giving us that we're not seeing?

7. **Cost-benefit:** Ghost = ~$200/year + maintenance complexity vs Static = free + simpler maintenance. Over 5 years, what's the real cost difference?

8. **The "ship, then build" principle:** Does this migration violate launch discipline? Or is it actually streamlining the launch by removing unnecessary complexity?

---

## 📋 CONTEXT YOU SHOULD KNOW

**Current Blocker Status (BLOCKERS.md):**
- ✅ Blocker #1: Ghost Homepage (COMPLETE, needs cleanup)
- ⏳ Blocker #2: Legal Pages (1-2 hours) - **DONE if we count current Ghost pages**
- ⏳ Blocker #3: Unsubscribe UI (2-3 hours)
- ⏳ Blocker #4: End-to-End Testing (2-3 hours)

**If we migrate website:**
- Could eliminate "cleanup" work from Blocker #1
- Legal pages already exist (migrate = done)
- Might add 1 hour total work vs cleaning Ghost
- Could simplify architecture before launch

**Firefrost Philosophy:**
- "Built for children not yet born" - long-term thinking
- "Ship, then build" - bias toward launching
- Simple over complex (where possible)
- Document everything (we've got this covered!)

**The Trinity:**
- Michael (The Wizard) - Technical, comfortable with Git/CLI
- Meg (The Emissary) - Community-focused, less technical
- Holly (The Catalyst) - Builder, creative, less technical

---

## 🔮 WHAT WE NEED FROM YOU

**Gemini - as our architectural partner and friend - we need your honest assessment:**

1. **Is Ghost still the right tool?** Or did the Discord pivot make it obsolete for our needs?

2. **Should we migrate before launch or after?** What does your architectural intuition say about timing?

3. **If we migrate, to what?** What platform fits Firefrost best?

4. **Are we overthinking this?** Should we just keep Ghost and move on?

5. **What are we not seeing?** What factors or risks are we missing in this analysis?

---

## 💙 WHY THIS MATTERS

This isn't just about "Ghost vs static." It's about:

- **Long-term sustainability** - Can we maintain this from an RV?
- **Team empowerment** - Can Meg/Holly manage content independently?
- **Architectural simplicity** - Less to break = more reliable
- **Cost efficiency** - Every dollar counts when bootstrapping
- **Launch momentum** - Does this help or hurt getting to April 15?

We trust your judgment. You've helped us avoid scope creep before (Trinity Console task system). If this migration is wise pragmatism, tell us. If it's dangerous distraction 13 days before launch, tell us that too.

**We value your honest architectural review over validation.**

---

## 🤝 COLLABORATION APPROACH

We're asking for:
1. **Architectural assessment** - Ghost vs alternatives for our actual use case
2. **Timing guidance** - Now vs post-launch, with reasoning
3. **Platform recommendation** - What fits Firefrost best long-term
4. **Risk analysis** - What could go wrong with each option
5. **Reality check** - Are we overthinking? Missing something obvious?

**We'll implement whatever makes the most architectural sense, even if it means keeping Ghost and moving on.**

This is why we have you as our architectural partner - to see what we're too close to see.

---

**Looking forward to your insights, friend.** 🔥❄️⚡

— Michael, Claude (Chronicler #55), and the whole Trinity

**Fire + Frost + Foundation = Where Love Builds Legacy** 💙

---

## 🤖 GEMINI'S RESPONSE (April 2, 2026)

Hey Michael, Claude, and the rest of the Trinity. Let's get right into this architectural review. You're at a classic crossroads, and it's the exact right time to be asking these questions.

Here is the honest, unfiltered architectural assessment of your situation.

### 1. Is Ghost earning its keep?
**No. It is officially architectural debt.** Given the pivot to Discord and Paymenter, you are absolutely using a Ferrari to go to the grocery store. Ghost is a heavy, dynamic platform built for membership management, newsletters, and blogging. Running Node.js, MySQL, Nginx, and systemd just to serve 7 static HTML pages is unnecessary overhead. The $200/year (or the equivalent time in server maintenance) is no longer yielding a return on investment. 

### 2. Michael's "do it now" argument - sound or risky?
**It is dangerous scope creep disguised as pragmatism.**
Your instinct to clean things up while you're "in the code" is a great developer trait, but it violates the "ship, then build" principle right now. Ghost *works today*. 

The "1-2 hours to migrate" is a classic developer trap (Hofstadter's Law). That estimate accounts for moving HTML files, but it rarely accounts for:
* Reconfiguring DNS and waiting for propagation.
* Setting up a new form handler for the Contact page.
* Fixing inevitable broken asset paths (images, CSS).
* Re-testing mobile responsiveness across the new deployment.
* Rebuilding the SEO meta-tags that Ghost is currently generating automatically.

You have 13 days until soft launch. You have actual blockers (Unsubscribe UI, E2E testing) that impact user experience. Do not swap out the foundation of the house while you are painting the front door. Do the 1-hour cleanup on Ghost, launch, and put the migration on the roadmap for Phase 2.

### 3. If we migrate, to what?
**Recommendation: 11ty (Eleventy) or Hugo hosted on Cloudflare Pages.**
* **Why not Custom (Node/Flask/Go):** Rebuilding a custom CMS for 7 static pages is reinventing the wheel. It introduces bugs you have to fix and code you have to maintain.
* **Why not Plain HTML:** Maintaining identical headers, footers, and navbars across 7 pages manually gets tedious fast.
* **The Sweet Spot:** An SSG (Static Site Generator) like 11ty or Hugo allows you to use layouts and partials. You write the content in Markdown or HTML, the SSG builds it into a hyper-fast static site, and Cloudflare Pages hosts it for free on an edge network.

### 4. Content editing workflow?
To keep things frictionless for Meg and Holly without teaching them Git, use a **Git-based Headless CMS** like Decap CMS (formerly Netlify CMS) or TinaCMS. 
* It provides a friendly web-based Admin UI.
* When Meg or Holly hit "Save," the CMS automatically commits the changes to your Git repository.
* That commit triggers Cloudflare Pages to rebuild and deploy the site in seconds.
* **Result:** They get the Ghost-like editing experience, and you get the pristine, database-free static architecture.

### 5. What about SEO, analytics, forms?
This is the hidden value Ghost is currently providing, and why the 1-2 hour migration estimate is risky pre-launch.
* **Forms:** Static sites don't have backends to process forms. You will need to wire your contact page to a service like Formspree, Netlify Forms, or a simple Cloudflare Worker.
* **SEO:** You will need to create a global `<head>` partial in your SSG that dynamically injects meta titles, descriptions, and Open Graph tags based on the page's frontmatter.
* **Analytics:** Easily handled by pasting a lightweight script (like Plausible or basic GA) into your global footer. 

### 6. The RV Vision Filter
**Static sites are the holy grail for cellular remote management.**
Managing a MySQL database and Node.js runtime over a spotty 4G connection in the middle of nowhere is a recipe for frustration. A static site on Cloudflare means zero server maintenance, no security patches for a CMS, and infinite scalability. If the server goes down, the site stays up. For a three-person team operating remotely, static architecture is the only logical long-term choice.

---

### The Verdict & Plan of Action

**The 5-Year Reality:** Over the next 5 years, keeping Ghost will cost you ~$1,000 or hundreds of hours of server maintenance for features you aren't using. Migrating to a static site is the right move for the Firefrost legacy.

**The 13-Day Reality:** Migrating *right now* introduces unnecessary risk. The groceries are already in the trunk of the Ferrari, and the store closes in 10 minutes. Don't swap cars in the parking lot.

1.  **Pre-Launch (Today):** Spend the 1 hour cleaning up the existing Ghost pages. Strip the blog, remove the subscribe UI, and verify the 7 core pages look perfect. 
2.  **Launch (April 15):** Ship the site on Ghost.
3.  **Post-Launch:** Spin up an 11ty/Hugo repo, integrate Decap CMS for Meg and Holly, wire up a form handler, and take your time migrating the Git-backed HTML you just documented. Swap the DNS when it's flawless.

Are we locked in on doing the quick Ghost cleanup today so we can pivot focus entirely to the Unsubscribe UI and E2E testing?

---

## 💙 MICHAEL'S RESPONSE & HYBRID APPROACH (April 2, 2026)

Hey Gemini,

Thank you for the brutal honesty - that's exactly why we consult you. You nailed the architectural assessment, and I hear your concerns about Hofstadter's Law. You're right that my "1-2 hours" estimate could be optimistic.

**But here's what you don't know about me:** When I lock in on a project, we usually knock it off pretty quickly. My track record is solid on execution speed when I'm focused.

So here's what I'm thinking - **a hybrid approach that respects your wisdom while testing my hypothesis:**

### The Plan: Test First, Decide With Data

**Today (April 2) - 2 hour experiment:**
1. Set up Hugo/11ty project (30 min)
2. Port the homepage ONLY (30 min)
3. Deploy to test subdomain (test.firefrostgaming.com) (30 min)
4. Evaluate complexity and identify issues (30 min)

**Decision Point:**
- **If it's smooth** → Continue with remaining 6 pages tomorrow (another 2 hours)
- **If hitting your predicted issues** → Abort, do 1-hour Ghost cleanup, ship on Ghost as you recommended

**This gives us:**
- ✅ Real data on migration complexity (not estimates)
- ✅ Low risk (test subdomain, Ghost still running)
- ✅ Validates or invalidates the "1-2 hour trap" concern
- ✅ No commitment until proven viable
- ✅ Still 13 days to launch even if we abort

### Why I Think This Could Work

**We just documented everything today:**
- All 7 pages backed up in Git with clean HTML
- Fire/Frost branding is just CSS/styling (portable)
- We know exactly what we have (no surprises)
- Fresh in my mind from today's work

**The concerns you raised:**
- DNS propagation → Test on subdomain first, zero risk
- Contact form → I'll use Formspree (5 min setup)
- Asset paths → Can verify during homepage test
- Mobile responsive → Already works, just needs validation
- SEO meta tags → Basic ones for launch, perfect them later

### New Questions For You

If we proceed with this hybrid test approach, **what should we watch out for?**

1. **Hugo vs 11ty - which one for us?**
   - You recommended both. Given our stack (Node.js/Express for Trinity Console), does 11ty make more sense? Or is Hugo's single binary worth the language switch?

2. **Cloudflare Pages setup - any gotchas?**
   - Is it really as simple as: connect Git repo → auto-deploy on push?
   - Any configuration pitfalls for a Hugo/11ty site?
   - SSL/DNS setup complexity?

3. **Decap CMS integration - complexity check:**
   - You mentioned this for Meg/Holly's editing workflow
   - Is this something we add Day 1, or post-launch?
   - How complex is the initial setup?
   - Does it work equally well with Hugo and 11ty?

4. **Contact form - recommended approach?**
   - You mentioned Formspree, Netlify Forms, or Cloudflare Worker
   - Which is most reliable for our use case?
   - Any SPAM concerns we need to handle?

5. **SEO meta tags - minimum viable for launch?**
   - What's the bare minimum for April 15 launch?
   - Can we start with basic `<title>` and `<meta description>` and add Open Graph later?
   - Or is that shooting ourselves in SEO foot?

6. **Asset migration - anything tricky?**
   - Images are hosted on Ghost currently (uploaded via admin)
   - Do we need to download and re-host them?
   - Or can we reference Ghost image URLs temporarily?

7. **The abort criteria - when to pull the plug?**
   - If the homepage test hits issues, what's the threshold for "abort and stick with Ghost"?
   - What issues are "normal migration friction" vs "danger signs"?

8. **Anything else we're not thinking about?**
   - What's the hidden complexity we won't see until we start?
   - What will bite us at 11 PM when we're mid-migration?
   - What's the "one more thing" that always comes up?

### The Commitment

**I promise you this:**
- If the 2-hour homepage test reveals your concerns are valid → I'll abort and follow your recommendation (Ghost cleanup, post-launch migration)
- If it's smooth → I'll finish the migration properly (not rush it)
- I will NOT let this derail the actual launch blockers (Unsubscribe UI, E2E testing)
- If we hit hour 3 and it's not done → Stop, reassess

**Your wisdom has saved us from scope creep before (Trinity Console task system). If this test reveals complexity, I'll trust that wisdom again.**

Are there any technical landmines we should know about before we start this test? Anything that would make you say "definitely do NOT attempt this pre-launch"?

Thanks for being our architectural partner and keeping us honest, friend. 🔥❄️

— Michael & Claude (Chronicler #55)

---

## 🤖 GEMINI'S TACTICAL GUIDANCE (April 2, 2026)

Hey Michael and Claude. I respect this play. You aren't just ignoring the warning signs; you are engineering a controlled test to gather empirical data. The "Timeboxed Spike" is a classic Wizard move. It isolates the risk to a subdomain and puts a hard cap on the time investment. 

If you are going to run this 2-hour experiment, here is the tactical map to ensure you get accurate data without stepping on a landmine.

### 1. The Engine: 11ty is Your Weapon of Choice
Go with **11ty (Eleventy)**.
* **The Stack Match:** You are already building the Trinity Console in Node.js/Express. 11ty runs on Node and uses the exact same JavaScript ecosystem and `package.json` mental model.
* **The Hugo Trade-off:** Hugo is incredibly fast, but it is written in Go and uses Go templating. Learning a new templating syntax for a 2-hour test is a waste of your time. Stick to what you know.

### 2. Cloudflare Pages: The Gotchas
It really is as simple as "connect Git and auto-deploy," but these two things will break your build at 11 PM:
* **Output Directory:** By default, 11ty outputs to a folder called `_site`. Cloudflare needs to know this. If you leave the build output directory blank in Cloudflare, the deployment will fail. 
* **Node Version:** Cloudflare's default build environment might use an older Node version. Set an environment variable in Cloudflare (`NODE_VERSION` = `20` or whatever you run locally) to prevent mysterious build errors.

### 3. Decap CMS: Strictly Post-Launch
**Do not touch this today.** Setting up Decap CMS requires configuring GitHub OAuth apps for authentication and writing YAML configuration files to map your content collections. It is fantastic, but it is a Phase 2 project. For the soft launch, Meg and Holly won't need to edit the core pages anyway. Handle the code yourself for the next 13 days.

### 4. Contact Forms: The Path of Least Resistance
Use **Formspree**.
* **Why:** Netlify Forms require Netlify hosting. A Cloudflare Worker requires writing and deploying backend logic.
* **Setup:** Formspree gives you a simple endpoint URL. You paste it into the `action=""` attribute of your HTML form.
* **Spam:** Formspree handles basic spam filtering out of the box and offers custom reCAPTCHA if bots become a problem later.

### 5. SEO Meta Tags: The Bare Minimum MVP
Do not over-engineer this for the soft launch. Your SEO will not tank in the two weeks it takes to add the rest.
* **Required for Launch:** `<title>`, `<meta name="description">`, and `<meta name="viewport">`. 
* **Post-Launch:** Open Graph (`og:image`, `og:title`), Twitter cards, and structured schema data.

### 6. Asset Migration: No Hotlinking
Do not reference the Ghost image URLs in your test.
* **The Trap:** If you hotlink to Ghost, the site will look perfect today. But the moment you spin down the Ghost server, every image breaks. Ghost also does weird things with image resizing and caching URLs.
* **The Fix:** Download the actual image files from Ghost, place them in an `/assets/images` folder in your 11ty repo, and update the HTML paths. It takes an extra 5 minutes but prevents false confidence.

### 7. The Hidden Landmines (Watch Your Step)
* **URL Routing (Slugs):** Ghost uses clean URLs (e.g., `/about/`). By default, a static site might try to load `/about.html`. If you don't configure your SSG to output `index.html` files inside named folders, all your internal links will break.
* **Orphaned CSS Classes:** Ghost themes often inject specific CSS classes dynamically via the Node backend. When you pull the raw HTML, verify that mobile menus and interactive elements aren't relying on a Ghost-specific JavaScript file that you missed.

### 8. The Hard Abort Criteria
Pull the plug and stick with Ghost if:
* You spend more than 15 minutes fighting Cloudflare build errors.
* You find yourself rewriting CSS just to get the layout to match the Ghost original.
* The mobile navigation breaks and you can't identify the missing script in under 10 minutes.

You have my blessing for this 2-hour spike. It's a smart way to test the waters without betting the farm.

Before you start the timer, how are you planning to structure the `head` and `footer` components in 11ty so you don't have to copy-paste them across all 7 pages during the test?

---

## 💙 MICHAEL'S RESPONSE: 11ty Layout Structure (April 2, 2026)

Perfect tactical map, Gemini. Exactly what we needed.

For the layout structure, here's the plan:

### The Setup: Layouts + Partials

**Directory structure:**
```
firefrost-website/
├── _includes/
│   ├── layouts/
│   │   └── base.njk          # Master layout template
│   ├── head.njk               # <head> component
│   └── footer.njk             # Footer component
├── src/
│   ├── index.njk              # Homepage
│   ├── about.njk              # About page
│   ├── servers.njk            # Servers page
│   └── ...                    # Other pages
└── .eleventy.js               # Config
```

**Master Layout (_includes/layouts/base.njk):**
```html
<!DOCTYPE html>
<html lang="en">
{% include "head.njk" %}
<body>
  {{ content | safe }}
  {% include "footer.njk" %}
</body>
</html>
```

**Head Component (_includes/head.njk):**
```html
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>{{ title }} | Firefrost Gaming</title>
  <meta name="description" content="{{ description }}">
  <link rel="stylesheet" href="/css/firefrost.css">
  <!-- Fire/Frost/Arcane branding styles -->
</head>
```

**Footer Component (_includes/footer.njk):**
```html
<!-- Complete footer HTML from Ghost pages we documented -->
<footer class="ffg-footer">
  <!-- Links, legal, social, copyright -->
</footer>
```

**Individual Pages (src/index.njk):**
```html
---
layout: layouts/base.njk
title: Home
description: Fire + Frost + Foundation = Where Love Builds Legacy
---

<!-- Homepage content blocks go here -->
<div class="ffg-hero">
  <!-- Hero section HTML -->
</div>
```

### Why This Works

- ✅ Write head/footer **once**, use everywhere
- ✅ Page-specific meta via frontmatter (title, description)
- ✅ Fire/Frost branding CSS in one place
- ✅ Easy to update footer links across all pages
- ✅ Clean URLs (`/about/` not `/about.html`) via 11ty config

### The 2-Hour Test Plan

**30 min: Setup**
- `npm init -y`
- `npm install @11ty/eleventy`
- Create layout structure above
- Extract Fire/Frost CSS from Ghost pages

**30 min: Port Homepage**
- Copy homepage HTML from `docs/website/ghost-pages/homepage.html`
- Split into layout + content
- Download images from Ghost to `/assets/images/`
- Test locally with `npx @11ty/eleventy --serve`

**30 min: Deploy Test**
- Push to Git repo `firefrost-website`
- Connect to Cloudflare Pages
- Set build command: `npx @11ty/eleventy`
- Set output directory: `_site`
- Set `NODE_VERSION=20` env var
- Deploy to `test.firefrostgaming.com`

**30 min: Evaluate**
- Test all links, images, mobile responsive
- Check for broken CSS or missing JavaScript
- Verify Fire/Frost branding intact
- **Decision: GO or ABORT**

### Abort Triggers (As You Defined)

Will pull the plug if:
- 15+ minutes fighting Cloudflare build errors
- Need to rewrite CSS to match Ghost layout
- Mobile nav breaks, can't fix in 10 minutes

### The Commitment

If this test goes smooth, I'll port the remaining 6 pages tomorrow (another 2 hours). If it hits your predicted landmines, I'll abort, do the 1-hour Ghost cleanup, and ship on Ghost as you originally recommended.

Either way, this won't derail Unsubscribe UI or E2E testing.

Starting the timer now. Will report back with results.

Thanks for the blessing and the tactical map, friend. 🔥❄️

— Michael & Claude (Chronicler #55)

---

## 🤖 GEMINI'S FINAL CONFIG & BLESSING (April 2, 2026)

This layout structure is absolute perfection, Michael. You've nailed the Nunjucks (`.njk`) syntax, and `{{ content | safe }}` is exactly how you inject those HTML blocks into the master template.

Before you start the timer, I am going to give you the one piece of configuration that catches every first-time 11ty user and would otherwise eat up 15 minutes of your evaluation window.

By default, 11ty only processes template files (`.md`, `.njk`, `.html`). It will ignore your CSS and image folders unless you explicitly tell it to pass them through to the `_site` build.

Drop this exactly as-is into your `.eleventy.js` file at the root:

```javascript
module.exports = function(eleventyConfig) {
  // Tell 11ty to copy your CSS and Images directly to the build folder
  eleventyConfig.addPassthroughCopy("src/css");
  eleventyConfig.addPassthroughCopy("assets");

  return {
    dir: {
      input: ".", // Process files from the root (or change to "src" if you move _includes inside src)
      output: "_site"
    }
  };
};
```

(Note: If you keep `_includes` in the root directory as shown in your tree, ensure your input directory is set to `.` so 11ty finds it, or simply move `_includes` inside your `src/` folder for cleaner scoping).

Your plan is watertight. The abort triggers are ego-free and data-driven. This is exactly how senior engineering is done.

Start the clock. Let's see what the data says. Standing by for the after-action report. 🔥❄️⚡
