Tag: Google Cloud

  • The Three-Legged Stack: Why I Stopped Shopping for New Tools

    The Three-Legged Stack: Why I Stopped Shopping for New Tools

    Last refreshed: May 15, 2026

    Companion piece: This article describes how the three-legged stack came together over fourteen months. For the full operating doctrine — why three legs specifically, what each leg’s job is, and how they hold each other up — see The Three-Legged Stack: Why I Run Everything on Notion, Claude, and Google Cloud. The two pieces complement each other; this one is the journey, that one is the doctrine.

    I almost got excited about Google’s Googlebook last week. Then I caught myself. I have a stack that’s starting to feel like a broken-in baseball glove — pocket exactly where I want it, leather oiled, laces holding. The last thing I need is a new glove.

    This is the operating philosophy I’ve landed on after a year of building Tygart Media as an AI-native content operation. It’s not a tech-stack post. It’s a posture. The stack I use — Claude as the intelligence layer, Notion as the control plane, GCP as the compute plane — happens to be the visual the rest of this piece is built around, but the real point is what holding still does to leverage.

    Walnut stool with copper, porcelain, and steel legs representing the Tygart Media AI operating stack of Claude, Notion, and GCP
    The Stack. Three legs is the minimum for stability. Add a fourth and you’ve added wobble, not strength.

    The temptation in any AI-adjacent business right now is to chase. Every week there is a new model, a new IDE, a new agent framework, a new laptop category. Googlebook arrives this fall promising Gemini at the kernel and an AI-powered cursor. OpenRouter sits there offering me every model in the world through one API. Six months ago I would have been wiring both of them in before the announcements cooled.

    I’m not doing that anymore. Here’s why, in seven images.

    The Three-Legged Stool

    Three legs is the minimum number for stability. Add a fourth and you haven’t added strength — you’ve added wobble. A three-legged stool sits flat on any surface, no matter how uneven, because three points define a plane. A four-legged stool needs the floor to be perfect, and if it isn’t, one leg is always lifting.

    My stack has three legs. Claude is the intelligence layer — every reasoning step, every draft, every architectural decision passes through it. Notion is the control plane — every project, client, task, ledger, and standard operating procedure lives there. Google Cloud Platform is the compute plane — Cloud Run services, BigQuery ledgers, Workload Identity Federation, the publisher infrastructure that moves content to 27 client sites without a single stored API key.

    People keep asking me when I’ll add a fourth leg. Will I move to OpenRouter for model diversity? Will I switch to Linear for project management? Will I migrate compute to AWS for the better startup credits? The honest answer is that adding a fourth leg right now would not make me more stable. It would make me less. I haven’t mastered the three I have.

    The Anvil and the Glove

    Walnut anvil on three legs with a worn baseball glove on top, sitting in a sunlit workshop
    Roots. Operations is operations. The discipline learned in restoration carries straight into AI-native content work.

    Before Tygart Media, I spent years in property damage restoration operations — Munters, Polygon, the kind of work where a phone call at 2 AM means a water line burst at a hotel and a crew needs to be on-site in forty-five minutes with the right equipment and the right paperwork. That world taught me everything I now use to run an AI-native content business. It taught me to batch. It taught me to absorb scope rather than push it back on the client. It taught me that subcontracting is a form of collaboration, not a failure mode. It taught me that operations is operations — the substrate changes, the discipline doesn’t.

    The baseball glove on top of the anvil is the metaphor I keep returning to. A new glove is stiff. It catches awkwardly. The webbing is too tight, the leather hasn’t formed to your hand yet, and every ball that comes in feels foreign. A broken-in glove is the opposite. It closes around the ball before you’ve consciously decided to squeeze. You don’t think about catching. You just catch.

    That’s what fourteen months on the same stack has done. I don’t think about how to publish to WordPress anymore. I don’t think about how to route a model decision between Haiku, Sonnet, and Opus. I don’t think about whether a new automation belongs in Cloud Run or as a Notion Worker. The catching is automatic. Every hour spent in the same three tools is another stitch in the glove.

    The Surveyor’s Tripod

    Surveyor's tripod with copper, porcelain, and steel legs planted on rocky ground at sunrise above the clouds
    Precision. The stack as a measurement instrument. Three legs, one truth.

    A tripod is a stool that measures. It’s the same three-legged geometry, but you put a sextant on top, or a transit, or a telescope, and suddenly the stability isn’t ornamental — it’s the whole point. If the legs aren’t planted, the measurement is wrong. If the measurement is wrong, you build in the wrong place.

    The three-legged stack as a measurement instrument is how I now think about content operations. Claude measures what to say. Notion measures what’s been said, what’s been promised, what’s been promoted, what’s been demoted. GCP measures what’s been deployed and what’s been logged. Together they make a single coherent reading of where the business actually is — not where I imagine it to be, not where I hope it is, but where it actually stands at 3 AM on a Tuesday.

    That reading is what lets me trust the work. The Promotion Ledger inside Notion tracks every autonomous behavior the system runs — content publishes, schema injections, taxonomy fixes, image optimizations — by tier and by clean-day count. Seven clean days on a tier means a candidate for promotion. A failure resets the clock. The instrument doesn’t lie. It either reads green or it doesn’t.

    The Trefoil

    Carved walnut trefoil with three interlocking loops of copper, porcelain, and steel meeting at a gold TM monogram
    Synthesis. Three loops meeting at the center. The synthesis point is where knowledge becomes a distillery.

    The trefoil is an ancient symbol — three interlocking loops meeting at a single point in the center. Heraldic shields use it. Cathedral architecture uses it. The Celtic version goes back to the Iron Age. It shows up everywhere because it answers a question every human system eventually asks: how do you get three independent things to produce a fourth thing that none of them could produce alone?

    Synthesis is the answer. Where the loops meet, the third thing happens. Claude alone is a smart conversation. Notion alone is a well-organized library. GCP alone is a pile of compute. None of those by themselves is a business. But the place where the three loops overlap — that’s where a client brief becomes a draft becomes an optimized article becomes a scheduled publish becomes a tracked outcome — and that center point is where the work actually lives.

    I think of Tygart Media as a Human Knowledge Distillery. The raw material is messy human knowledge — a client’s twenty years of trade experience, my own restoration background, a comedian’s stage instincts, a recovery contractor’s job-site stories. The distillery boils that down into something that can travel: an article, a schema block, a social post, a referral asset. The three legs aren’t doing the distilling. The synthesis at the center is.

    The Pocket Watch

    Open antique pocket watch on navy velvet with three mechanical bridges in copper, porcelain, and steel, TM monogram on the dial
    Mastery. Mechanism over magic. The watch doesn’t get better because a new watch came out.

    Independent horology — the world of small, fiercely independent watchmakers who build their movements by hand — is one of my private obsessions, and it has shaped how I think about AI tooling more than I expected. The watchmakers I admire most don’t release a new caliber every year. They spend a decade on one movement. They refine the escapement, balance the wheel, polish the bridges, and over time the watch gets better not because the parts are new but because the maker understands the parts better.

    This is the opposite of how most of the AI industry operates. The cadence is: ship a new model, ship a new agent, ship a new IDE, ship a new laptop. The implicit promise is that the latest thing will do more than the previous thing, and the implicit demand is that you keep up. Mastery is impossible in that mode. By the time you’ve learned the mechanism, the mechanism has been replaced.

    Holding still is a competitive advantage exactly because most people can’t. While everyone else is unboxing their Googlebook in October and figuring out where Gemini’s Magic Pointer fits into their workflow, my workflow won’t have changed — because the workflow doesn’t live on the laptop. It lives in the stack. The laptop is just a window into the stack. A new laptop is a new window. The view is the same.

    The Lighthouse

    Three-section lighthouse model with copper base, porcelain middle, and steel top projecting a warm beam through workshop fog
    Signal. Authority compounds when you stay put and keep the light on.

    Lighthouses don’t move. That’s the whole point of them. A lighthouse that wandered around the coastline trying to find the best vantage would not be useful to anyone — ships wouldn’t know where it was, the beam would never settle, and the entire purpose of having a fixed reference point in a foggy world would collapse.

    Content authority works the same way. The sites that get cited by AI models — that show up in Google’s AI Overviews, in Perplexity’s citations, in Claude’s own retrieval — are not the sites that pivoted the most. They are the sites that have been on the same beam for years, publishing the same kind of work, building the same kind of entity recognition, and giving language models a stable reference point to anchor to.

    This is true at the stack level too. The reason my content operations get more efficient month over month is not because I’m using new tools — it’s because Claude, Notion, and GCP have learned each other inside my workspace. The skill files in Claude know exactly which Notion databases to write to. The Notion routers know exactly which GCP services to dispatch. The GCP services know exactly which WordPress sites to publish to and how each one wants its content shaped. The beam is on. It keeps being on. Authority compounds in the version of you that didn’t move.

    The Hourglass

    Antique hourglass with three pillars of copper rope, porcelain grid, and brushed steel, golden sand falling onto polished gemstones
    Compounding. Time spent doesn’t drain. It crystallizes into something more valuable.

    This is the image that closes the piece, and it’s the one that took me the longest to understand. An hourglass usually represents time running out. Sand falls. The bulb empties. Eventually you’re done. The version I commissioned reframes it: golden sand falls into a bed of polished gemstones. Time doesn’t disappear into nothing. It compounds into something more valuable.

    That is the entire thesis of the broken-in glove. Time spent on the same stack does not drain. It crystallizes. Every additional week with Claude, Notion, and GCP makes the next week more leveraged, because the pattern library is bigger, the muscle memory is deeper, and the surface area I can act on without re-learning is wider. The opposite path — switching stacks, chasing the new thing, restarting the muscle memory — is the path where time actually drains. The bulb empties and there is no gemstone bed underneath.

    So when Googlebook launches in fall 2026 and people ask me whether I’m getting one, the answer is: maybe, eventually, as a window into the stack I already have. But not as a replacement for anything. The stool is the stool. The legs are the legs. And the glove is finally starting to feel like mine.

    Frequently Asked Questions

    What is the three-legged stack at Tygart Media?

    The three-legged stack is the operating system Tygart Media uses to run an AI-native content and SEO agency across 27+ client sites. The three legs are Claude as the intelligence layer, Notion as the control plane, and Google Cloud Platform as the compute plane. The architecture follows an Integration Spine: GitHub stores the source of truth, GitHub Actions plus Workload Identity Federation move work to Cloud Run with no stored credentials, and Cloud Run reports back to Notion.

    Why three tools instead of more?

    Three is the minimum number of points required to define a plane, which makes a three-legged structure inherently stable on any surface. Adding a fourth tool before mastering the first three adds switching cost and surface area without adding capability. Depth in three tools produces more leverage than breadth across six.

    How does the stack handle a 27-site content operation?

    Claude generates and optimizes content via skills that encode the standards for SEO, AEO, and GEO. Notion stores the editorial calendar, client briefs, Promotion Ledger, and the operating manual. GCP runs the Cloud Run publisher services that push optimized articles into WordPress sites via REST API, with all publishing actions logged back to Notion for audit. The stack is designed so that any single article passes through all three legs before going live.

    Is Tygart Media planning to adopt Googlebook when it launches?

    Not as a replacement for any part of the current stack. Googlebook will likely become useful as a thicker client surface over the same backend, but the actual operating system — Claude, Notion, GCP, and the Integration Spine — does not live on the laptop. The laptop is just a window into the stack. Switching laptops doesn’t change the view.

    What does “broken-in advantage” mean in an AI context?

    Broken-in advantage is the compounding effect that comes from sustained mastery of a single toolchain. Skills, automations, and muscle memory build on each other when the underlying tools stay constant. Operators who switch stacks frequently never reach the inflection point where the system becomes leveraged. Operators who hold still long enough to master the same three tools build a moat that’s harder to copy than any individual feature.

    Where does the restoration industry background fit in?

    Years of property damage restoration operations at Munters and Polygon taught the discipline that the AI-native content stack now runs on — batching, scope absorption, subcontracting as collaboration, and tiered trust systems. The thesis is that operations is operations. The substrate (restoration crews then, AI agents now) changes. The operating discipline doesn’t.

    How does the Promotion Ledger fit into the stack?

    The Promotion Ledger is a Notion database under a top-level page called The Bridge. Every autonomous behavior the system runs is tracked there by tier — A for proposed, B for human-flown, C for autonomous — with a clean-day counter and a failure log. Seven clean days on a tier qualifies a behavior for promotion. A failure resets the clock and demotes the behavior one tier. The Ledger is how the stack proves to itself that it can be trusted.

  • Google Drive + Notion AI: Bringing External Documents Into Agent Context

    Google Drive + Notion AI: Bringing External Documents Into Agent Context

    Google Drive + Notion AI: Bringing External Documents Into Agent Context

    The 60-second version

    Most teams have content split between Notion and Google Drive. Drive holds the “I’m collaborating in real-time with five people” docs; Notion holds the structured workspace and database content. The Drive integration lets agents read across both. The result: synthesis that pulls from “the project doc in Drive” plus “the project page in Notion” plus “the related research in Notion’s research database” without manual copy-paste.

    Three patterns that work

    1. Cross-source synthesis. “Summarize the state of project X” pulls from the Notion project page, the Google Doc collaborators are working in, and the Sheets file with the metrics. Agent produces one synthesis from three sources.
    2. Drive-content-as-source for Notion drafts. Drafting a Notion document, agent pulls from a Drive Doc as reference. Useful when the source-of-truth lives in Drive but the deliverable lives in Notion.
    3. Migration assistance. Teams moving from Drive to Notion can use the integration to surface “what’s still in Drive that should be in Notion.” Helps the migration without forcing it.

    What stays manual

    • The actual collaboration in Drive (real-time editing isn’t an agent task)
    • Decisions about which content lives where (organizational, not synthesis)
    • Sensitive Drive content the agent shouldn’t see (don’t connect it)

    Permission inheritance

    The Drive integration uses the connected user’s permissions. The agent sees what you see. Two practical implications:
    – For org-wide Drive content, connect through an account with broad access
    – For personal Drive, connect your personal account; the agent sees only your stuff

    Where this goes wrong

    1. Connecting too broadly. A Drive integration that gives the agent access to your entire org’s Drive includes things you didn’t think about (HR docs, finance, executive). Scope tightly.
    2. Letting Drive content lag behind Notion content. When a Notion page is canonical, the agent should reference it, not the Drive doc. Mark canonical sources clearly.
    3. Treating Drive as substrate without organization. A messy Drive feeds an agent that produces messy synthesis. The Editorial Surface Area thesis applies to Drive too.

    What to read next

    Editorial Surface Area, Slack Integration, Calendar + Notion AI, MCP foundation piece.

  • GCP-Powered CRM Touch Calendar Automation for Restoration Companies: Architecture Guide

    GCP-Powered CRM Touch Calendar Automation for Restoration Companies: Architecture Guide

    Who this is for: Your IT person, your developer, or a technical contractor. This brief describes a production-grade automation architecture for the restoration company CRM touch calendar using Google Cloud Platform (GCP). It assumes basic familiarity with cloud infrastructure, command line tools, and web APIs. It does not require deep expertise in any single area — the implementation is intentionally modular so that each component can be handed to a different person if needed.

    The business strategy this automates is in Your CRM Is Not a Lead Database. The manual version of this system is in the Email Automation Setup Guide. This brief is for teams who want to reduce ongoing manual work and build a more robust, scalable version of the same workflow.


    What This Architecture Automates

    The manual system requires a person to: export contacts from the CRM, validate emails, import to Mailchimp or Brevo, configure each campaign, schedule it, and log results back to Notion. For 4–6 campaigns per year, this is manageable manually. For a company running 10–15 campaigns across multiple divisions or service areas, or for an agency running this system for multiple restoration clients, a GCP automation layer eliminates the recurring labor.

    What this architecture handles automatically:

    • Scheduled contact export from ServiceTitan or Jobber via API
    • Segmentation and deduplication logic
    • Email validation pass before import
    • Contact import to Mailchimp or Brevo
    • Campaign creation from template stored in Cloud Storage
    • Campaign scheduling per the calendar in Notion
    • Results logging back to Notion after send

    What still requires human review:

    • Email copy review before scheduling (always — no automation should skip this)
    • Reply triage and qualitative logging
    • Warmth scoring and super-connector identification

    Prerequisites

    • A Google Cloud Platform account with billing enabled (new GCP accounts include $300 in free credits)
    • ServiceTitan or Jobber API access (ServiceTitan requires contacting their enterprise team; Jobber API is available on Connect plan and above at $119–$169/month)
    • Mailchimp account with API access (available on all paid plans) OR Brevo with API access (all plans)
    • Notion account with Notion API integration enabled (free at notion.com/my-integrations)
    • Basic Python familiarity (this implementation uses Python 3.11+)

    Architecture Overview

    ┌─────────────────────────────────────────────────────────────┐
    │                    TRIGGER LAYER                            │
    │  Cloud Scheduler → cron job on campaign dates from Notion   │
    └────────────────────────────┬────────────────────────────────┘
                                 │
    ┌────────────────────────────▼────────────────────────────────┐
    │                 ORCHESTRATION LAYER (Cloud Run)             │
    │  campaign-runner service — reads Notion calendar,           │
    │  determines which campaigns are due, triggers pipeline      │
    └────────────────────────────┬────────────────────────────────┘
                                 │
             ┌───────────────────┼───────────────────┐
             │                   │                   │
    ┌────────▼────────┐ ┌───────▼────────┐ ┌────────▼────────┐
    │  CONTACT SYNC   │ │ TEMPLATE STORE │ │  RESULTS LOGGER │
    │  Cloud Run      │ │  Cloud Storage │ │  Cloud Run      │
    │  - CRM export   │ │  - Email copy  │ │  - Poll email   │
    │  - Segment      │ │  - Subject     │ │    platform     │
    │  - Dedupe       │ │    variants    │ │  - Write Notion │
    │  - Validate     │ │  - Prompt lib  │ │  - Update touch │
    │  - Import to    │ │                │ │    log          │
    │    email        │ └────────────────┘ └─────────────────┘
    │    platform     │
    └─────────────────┘
    

    Component 1: GCP Project Setup

    # Install gcloud CLI and authenticate
    gcloud auth login
    gcloud projects create restoration-crm-[yourcompany] --name="Restoration CRM Automation"
    gcloud config set project restoration-crm-[yourcompany]
    
    # Enable required APIs
    gcloud services enable \
      run.googleapis.com \
      cloudscheduler.googleapis.com \
      secretmanager.googleapis.com \
      storage.googleapis.com
    
    # Create service account for the automation
    gcloud iam service-accounts create crm-automation-sa \
      --display-name="CRM Automation Service Account"
    
    # Grant necessary permissions
    gcloud projects add-iam-policy-binding restoration-crm-[yourcompany] \
      --member="serviceAccount:crm-automation-sa@restoration-crm-[yourcompany].iam.gserviceaccount.com" \
      --role="roles/run.invoker"
    

    Component 2: Secret Manager for API Credentials

    Store all API credentials in GCP Secret Manager. Never hardcode credentials in source code.

    # Store each credential as a separate secret
    echo -n "your-servicetitan-api-key" | gcloud secrets create servicetitan-api-key \
      --data-file=-
    
    echo -n "your-jobber-api-key" | gcloud secrets create jobber-api-key \
      --data-file=-
    
    echo -n "your-mailchimp-api-key" | gcloud secrets create mailchimp-api-key \
      --data-file=-
    
    echo -n "your-notion-token" | gcloud secrets create notion-token \
      --data-file=-
    
    # In Python, access secrets like this:
    # from google.cloud import secretmanager
    # client = secretmanager.SecretManagerServiceClient()
    # name = f"projects/{project_id}/secrets/{secret_id}/versions/latest"
    # response = client.access_secret_version(request={"name": name})
    # secret_value = response.payload.data.decode("UTF-8")
    

    Component 3: Contact Sync Service

    This Cloud Run service handles the contact export → segment → validate → import pipeline. Deploy as a container triggered by the orchestration layer.

    # contact_sync/main.py
    
    import os
    import json
    import requests
    from google.cloud import secretmanager
    
    def get_secret(secret_id):
        client = secretmanager.SecretManagerServiceClient()
        project_id = os.environ.get("GCP_PROJECT_ID")
        name = f"projects/{project_id}/secrets/{secret_id}/versions/latest"
        response = client.access_secret_version(request={"name": name})
        return response.payload.data.decode("UTF-8")
    
    def export_jobber_contacts():
        """Export residential clients from Jobber API"""
        api_key = get_secret("jobber-api-key")
        
        # Jobber uses GraphQL API
        query = """
        query GetClients($after: String) {
          clients(first: 100, after: $after) {
            nodes {
              id
              firstName
              lastName
              emails { address isPrimary }
              tags { label }
              jobs(first: 1) {
                nodes { jobType completedAt }
              }
            }
            pageInfo { hasNextPage endCursor }
          }
        }
        """
        
        headers = {
            "Authorization": f"Bearer {api_key}",
            "Content-Type": "application/json"
        }
        
        contacts = []
        cursor = None
        
        while True:
            variables = {"after": cursor} if cursor else {}
            response = requests.post(
                "https://api.getjobber.com/api/graphql",
                headers=headers,
                json={"query": query, "variables": variables}
            )
            data = response.json()
            clients = data["data"]["clients"]
            
            for client in clients["nodes"]:
                email = next(
                    (e["address"] for e in client["emails"] if e["isPrimary"]),
                    client["emails"][0]["address"] if client["emails"] else None
                )
                if not email:
                    continue
                
                # Determine segment based on tags
                tags = [t["label"].lower() for t in client["tags"]]
                if "residential" in tags or not any(t in tags for t in ["commercial", "adjuster", "vendor"]):
                    segment = "Homeowner"
                elif any(t in tags for t in ["adjuster", "agent", "insurance"]):
                    segment = "Industry"
                else:
                    segment = "Trade"
                
                # Get most recent job type
                job_type = None
                if client["jobs"]["nodes"]:
                    job_type = client["jobs"]["nodes"][0].get("jobType", "")
                
                contacts.append({
                    "first_name": client["firstName"],
                    "last_name": client["lastName"],
                    "email": email.lower().strip(),
                    "segment": segment,
                    "job_type": job_type or ""
                })
            
            if not clients["pageInfo"]["hasNextPage"]:
                break
            cursor = clients["pageInfo"]["endCursor"]
        
        return contacts
    
    def deduplicate_contacts(contacts):
        """Remove duplicate emails, keep most recent record"""
        seen = {}
        for contact in contacts:
            email = contact["email"]
            if email not in seen:
                seen[email] = contact
        return list(seen.values())
    
    def segment_contacts(contacts):
        """Split into three segment lists"""
        segments = {"Homeowner": [], "Industry": [], "Trade": []}
        for contact in contacts:
            seg = contact.get("segment", "Homeowner")
            if seg in segments:
                segments[seg].append(contact)
        return segments
    
    def import_to_mailchimp(contacts, tag, api_key, list_id):
        """Batch import contacts to Mailchimp with tag"""
        
        # Mailchimp batch operations (max 500 per call)
        batch_size = 500
        
        for i in range(0, len(contacts), batch_size):
            batch = contacts[i:i+batch_size]
            
            operations = []
            for contact in batch:
                operations.append({
                    "method": "PUT",
                    "path": f"/lists/{list_id}/members/{contact['email'].encode().hex()}",
                    "body": json.dumps({
                        "email_address": contact["email"],
                        "status_if_new": "subscribed",
                        "merge_fields": {
                            "FNAME": contact.get("first_name", ""),
                            "LNAME": contact.get("last_name", ""),
                            "JOB_TYPE": contact.get("job_type", "")
                        },
                        "tags": [tag]
                    })
                })
            
            response = requests.post(
                "https://us1.api.mailchimp.com/3.0/batches",
                auth=("anystring", api_key),
                json={"operations": operations}
            )
            
            if response.status_code not in [200, 201]:
                raise Exception(f"Mailchimp batch import failed: {response.text}")
        
        return len(contacts)
    
    def run_contact_sync(request):
        """Main Cloud Run handler"""
        mailchimp_api_key = get_secret("mailchimp-api-key")
        mailchimp_list_id = os.environ.get("MAILCHIMP_LIST_ID")
        
        contacts = export_jobber_contacts()
        contacts = deduplicate_contacts(contacts)
        segments = segment_contacts(contacts)
        
        results = {}
        for segment_name, segment_contacts in segments.items():
            count = import_to_mailchimp(
                segment_contacts,
                tag=segment_name,
                api_key=mailchimp_api_key,
                list_id=mailchimp_list_id
            )
            results[segment_name] = count
        
        return json.dumps({"status": "success", "imported": results})
    

    Component 4: Cloud Scheduler Trigger

    Cloud Scheduler runs the orchestration service on the campaign dates stored in your Notion calendar. The scheduler checks Notion weekly for upcoming campaigns and pre-triggers the contact sync 7 days before each scheduled send.

    # Create weekly scheduler job
    gcloud scheduler jobs create http crm-weekly-check \
      --schedule="0 9 * * 1" \
      --uri="https://[cloud-run-url]/check-upcoming-campaigns" \
      --oidc-service-account-email="crm-automation-sa@[project].iam.gserviceaccount.com" \
      --time-zone="America/Los_Angeles" \
      --location="us-west1"
    

    The orchestration service reads your Notion Campaign Calendar database, finds any campaigns with a send date within the next 7 days and a Status of “Scheduled,” and triggers the contact sync and campaign creation pipeline for each one.


    Component 5: Results Logger

    After each campaign sends, this service polls the Mailchimp or Brevo API for campaign analytics and writes them back to your Notion Campaign Calendar database.

    # results_logger/main.py (simplified)
    
    def log_campaign_results(campaign_id, notion_page_id):
        mailchimp_api_key = get_secret("mailchimp-api-key")
        notion_token = get_secret("notion-token")
        
        # Get Mailchimp campaign report
        response = requests.get(
            f"https://us1.api.mailchimp.com/3.0/reports/{campaign_id}",
            auth=("anystring", mailchimp_api_key)
        )
        report = response.json()
        
        open_rate = report.get("opens", {}).get("open_rate", 0)
        
        # Update Notion page
        notion_headers = {
            "Authorization": f"Bearer {notion_token}",
            "Content-Type": "application/json",
            "Notion-Version": "2022-06-28"
        }
        
        requests.patch(
            f"https://api.notion.com/v1/pages/{notion_page_id}",
            headers=notion_headers,
            json={
                "properties": {
                    "Status": {"select": {"name": "Sent"}},
                    "Open Rate": {"number": round(open_rate * 100, 1)}
                }
            }
        )
    

    Estimated Monthly GCP Costs

    For a single restoration company running 6 campaigns per year:

    Service Usage Monthly Cost
    Cloud Run (contact sync) 6 invocations/year, <5min each <$1
    Cloud Scheduler 52 weekly checks/year $0.10
    Cloud Storage (templates) Minimal storage <$0.01
    Secret Manager 4 secrets, <1000 accesses/month <$0.10
    Total <$2/month

    For an agency running this system for 10 restoration clients simultaneously, the cost scales linearly — approximately $15–20/month in GCP costs for the full multi-client operation. The manual labor savings at that scale are significant: an estimated 8–12 hours per month of manual campaign setup eliminated.


    Deployment Checklist

    • GCP project created and APIs enabled
    • Service account created with appropriate permissions
    • All API credentials stored in Secret Manager
    • Contact sync service containerized and deployed to Cloud Run
    • Cloud Scheduler job created and tested
    • Notion Campaign Calendar database connected
    • Results logger deployed and tested with a historical campaign
    • Full end-to-end test run on a staging contact list before live deployment

    Full documentation for each GCP service referenced here: cloud.google.com/run/docs, cloud.google.com/scheduler/docs, cloud.google.com/secret-manager/docs.


  • The Company OS: What If I Just Ran Your Entire Business and Took a Cut?

    The Company OS: What If I Just Ran Your Entire Business and Took a Cut?

    I’ve been the outside SEO guy for a while now. The vendor. The person you call when your rankings drop or your Google Ads are bleeding money. You pay a retainer, I do the work, and at the end of the month you squint at a report trying to figure out if it was worth it.

    I’ve been thinking about burning that model down.

    Not because it doesn’t work — it does. But because it fundamentally undersells what I can actually do, and it puts me in a position where I’m always justifying my existence to someone who doesn’t fully understand what I built for them. There’s a better arrangement. And I think I finally figured out what it looks like.

    Here’s the idea: instead of being your marketing vendor, what if I became your entire revenue infrastructure?

    Company OS — Digital Control Room Hero
    The Company OS lives on a dedicated Google Cloud VM — your business’s own server environment, fully managed.

    What I’m Calling the Company OS

    I build a lot of things for the businesses I work with. Websites. Content engines. Ad campaigns. Call tracking. CRM setups. AI agents that handle intake and follow-up. I’ve been doing all of this across multiple companies at once. At some point I started noticing that the companies where I’m most involved — where I’m running the full stack, not just one piece — perform dramatically better than the ones where I’m just “doing SEO.”

    So I started asking: what if I just owned the whole stack, hosted it, and took a percentage of what I could prove I drove?

    That’s the Company OS. Here’s what’s in the box:

    • A dedicated Google Cloud VM — your company’s own server environment that I host and manage
    • Your website, fully built and optimized by me
    • AI-generated content at scale — the kind that dominates local search
    • Google Ads and Local Service Ads managed by me
    • Call Track Metrics wired to every traffic source — every call tracked to the page, the keyword, the campaign, the full journey
    • A CRM and project management tools for your crew
    • AI agents handling intake, follow-up, and estimate coordination
    Company OS — What's In The Box
    Every node in the network — website, ads, calls, CRM, AI agents — connected and managed as one system.

    The contractor pays nothing upfront. No retainer. No setup fee. They owe me a percentage of every verified dollar of revenue that came through my system. Call Track Metrics makes it provable. We both look at the same data.

    The Numbers I’m Working With

    I started this in the restoration contracting space because that’s the vertical I know cold, but the model generalizes to any business where the lead is a phone call.

    A mid-size restoration contractor doing $150,000/month in revenue is not unusual in a decent market. Here’s what my costs look like to run the OS for one client: the Google Cloud VM runs about $60–90/month, Call Track Metrics is $150–250/month, content production runs $200–400/month, CRM and project management tools are another $100–200/month. The big variable is Google Ads spend, which I front — somewhere between $2,000–5,000/month depending on the market.

    All in, I’m spending $4,000–7,500/month to run the OS for one contractor, including ad spend I’m fronting out of pocket.

    At 15% commission on a $150K/month contractor, I’m making $22,500 gross and netting around $15,000–18,000 after fully-loaded costs. Three contractors at that level is $45,000–54,000/month net. Five is north of $80,000/month.

    Compare that to what contractors are currently paying for leads. HomeAdvisor sells the same lead to four contractors at $80–200 per lead with a 15–25% close rate — your effective cost per job is $400–1,200, and there’s zero attribution on whether it was a good lead or junk. Thumbtack is similar. My model: you pay nothing unless revenue comes in, and we both know exactly where it came from.

    What Makes This Actually Different

    There are agencies that do some of this. There are MSPs that host infrastructure. There are lead gen companies that take a fee per lead. What makes this different is that all three things have to be true at the same time.

    I own the full stack. Not just ads, not just SEO — the website, the content, the tracking, the CRM, the AI agents. When you remove a piece, the whole thing works less well. That integration is the moat.

    Attribution is verifiable. Call Track Metrics is the key that makes the commission model honest. Without traceable data, a performance arrangement is a trust exercise. With CTM, it’s just math. Every party sees the same numbers.

    I absorb the cost and the risk. I front the ad spend. I pay for the infrastructure. This is not a retainer with a performance kicker — this is genuinely performance-only. That’s a fundamentally different ask of the client and a fundamentally different commitment from me.

    Company OS — Verified Attribution Dashboard
    Every call verified. Every dollar attributed. Call Track Metrics makes the commission model honest — no arguments about where the revenue came from.

    I haven’t seen anyone do all three cleanly. There are pieces of it everywhere. But not the whole thing, not in one managed system, not with the attribution layer that makes it honest.

    What Could Go Wrong (Because I Should Be Honest About This)

    The scariest scenario: I front $3,000–5,000 in Google Ads for a contractor and their office can’t close the calls I send them. The leads are real — qualified calls from people with water damage or fire damage — but if the contractor answers poorly or doesn’t follow up, those jobs don’t close and my commission is zero. I’ve eaten the ad spend.

    Mitigation: I don’t take on clients whose operations are a mess. I build an AI intake agent so the first response to every inbound call is handled by my system. And I put a close-rate floor in the contract — if it drops below a threshold, we either fix it or I exit.

    The second risk: at some point a contractor doing $300K/month realizes they’re paying me $45K/month, every month, and they start looking for the exit. The answer is that the infrastructure I’ve built is genuinely hard to replicate — the domain authority, the content history, the CTM data — and I should be open to renegotiating toward a hybrid model as relationships mature. Don’t be greedy enough to kill a good thing.

    Third: Google changes local search. This is always true and always real. But the moat isn’t just SEO. The call tracking, the CRM, the AI intake — I own the communication infrastructure. Even if search displays change, I still own the pipeline.

    The Bigger Picture

    Company OS — The Bigger Picture
    One VM. One system. Scalable to any vertical where the lead is a phone call and the conversion is trackable.

    This started as a restoration contracting idea but I keep thinking about the generalization. The Company OS is not vertical-specific. Anything with a traceable phone-call revenue model could work. HVAC. Plumbing. Roofing. Personal injury law. Dental. Any business where the lead is a call and the conversion is trackable.

    The risk of thinking too broadly too early is that I spread myself before I’ve proven the model in one vertical. Restoration is where I have the deepest knowledge and the most infrastructure already built. That’s where this starts.

    But the generalization potential is real. If the model works in restoration, the playbook exists. Every vertical is just a new instance of the OS spun up on a new VM with vertical-specific content and keyword strategy.


    I’m writing this publicly because I want the pressure of having said it out loud. This is a big change in how I think about my work and my offer. I’m not an SEO vendor anymore — or at least, I don’t want to be. The Company OS is the more honest version of what I’ve actually been building toward.

    How does this age? I’ll find out.

  • Digital Fortress — GCP Security Architecture

    Digital Fortress — GCP Security Architecture

    Aerial view of a digital fortress representing GCP security architecture with layered encryption and secured data channels
  • Google Flow Brand Asset Production Testing — Tygart Media Visuals Visual

    Google Flow Brand Asset Production Testing — Tygart Media Visuals Visual

    Editorial illustration for We Tested Google Flow for Brand Asset Production - Tygart Media AI-generated visual
    Editorial illustration for We Tested Google Flow for Brand Asset Production – Tygart Media AI-generated visual

    About This Image

    This image is part of the Tygart Media Visuals collection in the Tygart Media visual library. Every image produced by Tygart Media is AI-generated using Google Vertex AI (Imagen), converted to WebP format, and injected with full IPTC/XMP metadata before publication.

    Technical Details

    • Format: WEBP
    • Collection: Tygart Media Visuals
    • Media ID: 1296
    • Pipeline: Vertex AI Imagen → WebP → IPTC/XMP → WordPress

    Image Licensing

    All images in the Tygart Media visual library are produced in-house using AI image generation and are owned by Tygart Media.

  • GCP Fortress Vertex AI — Article Hero Images Visual

    GCP Fortress Vertex AI — Article Hero Images Visual

    Gcp Fortress Vertex Ai
    Gcp Fortress Vertex Ai

    About This Image

    This image is part of the Article Hero Images collection in the Tygart Media visual library. Every image produced by Tygart Media is AI-generated using Google Vertex AI (Imagen), converted to WebP format, and injected with full IPTC/XMP metadata before publication.

    Technical Details

    • Format: WEBP
    • Collection: Article Hero Images
    • Media ID: 365
    • Pipeline: Vertex AI Imagen → WebP → IPTC/XMP → WordPress

    Image Licensing

    All images in the Tygart Media visual library are produced in-house using AI image generation and are owned by Tygart Media.

  • The Site Factory: How One GCP Instance Runs 23 WordPress Sites With AI on Autopilot

    The Site Factory: How One GCP Instance Runs 23 WordPress Sites With AI on Autopilot

    The Machine Room · Under the Hood

    TL;DR: We replaced 100+ isolated Cloud Run services with a single Compute Engine VM running 23 WordPress sites, a unified Content Engine, and autonomous AI workflows — cutting hosting costs to $15-25/site/month while launching new client sites in under 10 minutes.

    The Problem With One Site, One Stack

    When we started managing WordPress sites for clients at Tygart Media, each site got its own infrastructure: a Cloud Run container, its own database, its own AI pipeline, its own monitoring. At 5 sites, this was manageable. At 15, it was expensive. At 23, it was architecturally insane — over 100 Cloud Run services spinning up and down, each billing independently, each requiring separate deployments and credential management.

    The monthly infrastructure cost was approaching $2,000 for what amounted to medium-traffic WordPress sites. The cognitive overhead was worse: updating a single AI optimization skill meant deploying it 23 times.

    So we built the Site Factory.

    Three-Layer Architecture

    The Site Factory runs on a three-layer model that separates shared infrastructure from per-site WordPress instances and AI operations.

    Layer 1: Shared Platform (GCP). A single Compute Engine VM hosts all 23 WordPress installations with a shared MySQL instance and a centralized BigQuery data warehouse. A single Content Engine — one Cloud Run service — handles all AI-powered content operations across every site. A Site Registry in BigQuery maps every site to its credentials, hosting configuration, and optimization schedule.

    Layer 2: Per-Site WordPress. Each WordPress installation lives in its own directory on the VM with its own database. They share the same PHP runtime, Nginx configuration, and SSL certificates, but their content and configurations are completely isolated. Hosting cost per site: $15-25/month, compared to $80-150/month on containerized Cloud Run.

    Layer 3: Claude Operations. This is where the Expert-in-the-Loop architecture meets WordPress at scale. Routine operations — SEO scoring, schema injection, internal linking audits, AEO refreshes — run autonomously via Cloud Scheduler. Strategic operations — content strategy, complex article writing, taxonomy redesign — route to an interactive AI session where Claude operates as a system administrator with full context about every site in the registry.

    The Model Router

    Not every AI task requires the same model. Schema injection? Haiku handles it in 2 seconds at $0.001. A nuanced 2,000-word article on luxury asset lending? That’s Opus territory. SERP data extraction? Gemini is faster and cheaper.

    The Model Router is a centralized Cloud Run service that accepts task requests and dynamically routes them to the cheapest capable model on Vertex AI. It evaluates task complexity, required output length, and domain specificity, then selects the optimal model. This alone cut our AI compute costs by 40% compared to routing everything through a single frontier model.

    10-Minute Site Launch

    Adding a new client site to the factory takes 5 configuration steps and under 10 minutes:

    Register the domain and SSL certificate in Nginx. Create the WordPress database and installation directory. Add the site to the BigQuery Site Registry with credentials and vertical classification. Run the initial site audit to establish a content baseline. Enable the autonomous optimization schedule.

    From that point, the site receives the same AI optimization pipeline as every other site in the factory: daily content scoring, weekly SEO/AEO refreshes, monthly schema audits, and continuous internal linking optimization. No additional infrastructure. No new Cloud Run services. No incremental hosting cost beyond the shared VM allocation.

    Self-Healing Loop

    At 23 sites, things break. APIs rate-limit. WordPress plugins conflict. SSL certificates expire. The Self-Healing Loop monitors every site and every API endpoint continuously.

    When a WordPress REST API call fails, the system retries with exponential backoff. If the failure persists, it falls back to WP-CLI over SSH. If the site is completely unreachable, it triggers a Slack alert to the operations channel and pauses that site’s optimization schedule until the issue is resolved.

    For AI model failures, the Model Router implements automatic fallback: if Opus returns a 429 (rate limited), the task routes to Sonnet. If Sonnet fails, it queues for batch processing overnight at reduced rates. No task is ever dropped — only deferred.

    Cross-Site Intelligence

    The real power of the Site Factory isn’t cost reduction — it’s the intelligence layer that emerges when 23 sites share a single data warehouse. BigQuery holds content performance data, keyword rankings, schema coverage, and information density scores for every post on every site.

    This enables cross-site pattern recognition that’s impossible when sites operate in isolation. When an article format performs well on one site, the system can identify similar opportunities across all 22 other sites. When a keyword strategy drives organic growth in one vertical, the Content Engine can adapt that strategy for adjacent verticals automatically.

    The Site Factory isn’t a hosting solution. It’s an operating system for AI-powered content operations — one that gets smarter with every site we add.

    {
    “@context”: “https://schema.org”,
    “@type”: “Article”,
    “headline”: “The Site Factory: How One GCP Instance Runs 23 WordPress Sites With AI on Autopilot”,
    “description”: “One GCP Compute Engine VM, 23 WordPress sites, autonomous AI optimization, $15-25/site/month hosting costs, and new client sites launching in under 10 minutes. “,
    “datePublished”: “2026-03-30”,
    “dateModified”: “2026-04-03”,
    “author”: {
    “@type”: “Person”,
    “name”: “Will Tygart”,
    “url”: “https://tygartmedia.com/about”
    },
    “publisher”: {
    “@type”: “Organization”,
    “name”: “Tygart Media”,
    “url”: “https://tygartmedia.com”,
    “logo”: {
    “@type”: “ImageObject”,
    “url”: “https://tygartmedia.com/wp-content/uploads/tygart-media-logo.png”
    }
    },
    “mainEntityOfPage”: {
    “@type”: “WebPage”,
    “@id”: “https://tygartmedia.com/the-site-factory-how-one-gcp-instance-runs-23-wordpress-sites-with-ai-on-autopilot/”
    }
    }

  • Service Account Keys, Vertex AI, and the GCP Fortress

    Service Account Keys, Vertex AI, and the GCP Fortress

    The Machine Room · Under the Hood

    For regulated verticals (HIPAA, financial services, legal), we build isolated AI infrastructure on Google Cloud using service accounts, VPCs, and restricted APIs. This gives us Vertex AI and Claude capabilities without compromising data isolation or compliance requirements.

    The Compliance Problem
    Some clients operate in verticals where data can’t flow through public APIs. A healthcare client can’t send patient information to Claude’s public API. A financial services client can’t route transaction data through external language models.

    But they still want AI capabilities: document analysis, content generation, data extraction, automation.

    The solution: isolated GCP infrastructure that clients own, that uses service accounts with restricted permissions, and that keeps data inside their VPC.

    The Architecture
    For each regulated client, we build:

    1. Isolated GCP Project
    Their own Google Cloud project, separate billing, separate service accounts, zero shared infrastructure with other clients.

    2. Service Account with Minimal Permissions
    A service account that can only:
    – Call Vertex AI APIs (nothing else)
    – Write to their specific Cloud Storage bucket
    – Log to their Cloud Logging instance
    – No ability to access other projects, no IAM changes, no network modifications

    3. Private VPC
    All Vertex AI calls happen inside their VPC. Data never leaves Google’s network to hit public internet.

    4. Vertex AI for Regulated Workloads
    We use Vertex AI’s enterprise models (Claude, Gemini) instead of the public APIs. These are deployed to their VPC and their service account. Zero external API calls for language model inference.

    The Data Flow
    Example: A healthcare client wants to analyze patient documents.
    – Client uploads PDF to their Cloud Storage bucket
    – Cloud Function (with restricted service account) triggers
    – Function reads the PDF
    – Function sends to Vertex AI Claude endpoint (inside their VPC)
    – Claude extracts structured data from the document
    – Function writes results back to client’s bucket
    – Everything stays inside the VPC, inside the project, inside the isolation boundary

    The client can audit every API call, every service account action, every network flow. Full compliance visibility.

    Why This Matters for Compliance
    HIPAA: Patient data never leaves the healthcare client’s infrastructure
    PCI-DSS: Payment data stays inside their isolated environment
    GDPR: EU data can be processed in their EU GCP region
    FedRAMP: For government clients, we can build on GCP’s FedRAMP-certified infrastructure

    The Service Account Model
    Service accounts are the key to this. Instead of giving Claude/Vertex AI direct access to client data, we create a bot account that:

    1. Has zero standing permissions
    2. Can only access specific resources (their bucket, their dataset)
    3. Can only run specific operations (Vertex AI API calls)
    4. Permissions are short-lived (can be revoked immediately)
    5. Every action is logged with the service account ID

    So even if Vertex AI were compromised, it couldn’t access other clients’ data. Even if the service account was compromised, it couldn’t do anything except Vertex AI calls on that specific bucket.

    The Cost Trade-off
    – Shared GCP account: ~$300/month for Claude/Vertex AI usage
    – Isolated GCP project per client: ~$400-600/month per client (slightly higher due to overhead)

    That premium ($100-300/month per client) is the cost of compliance. Most regulated clients are willing to pay it.

    What This Enables
    – Healthcare clients can use Claude for chart analysis, clinical note generation, patient data extraction
    – Financial clients can use Claude for document analysis, regulatory reporting, trade summarization
    – Legal clients can use Claude for contract analysis, case law research, document review
    – All without violating data residency, compliance, or isolation requirements

    The Enterprise Advantage
    This is where AI agencies diverge from freelancers. Most freelancers can’t build compliant AI infrastructure. You need GCP expertise, service account management knowledge, and regulatory understanding.

    But regulated verticals are where the money is. A healthcare data extraction project can be worth $50K+. A financial compliance project can be $100K+. The infrastructure investment pays for itself on the first client.

    If you’re only doing public API integrations, you’re leaving regulated verticals entirely on the table. Build the fortress. The clients are waiting.

    {
    “@context”: “https://schema.org”,
    “@type”: “Article”,
    “headline”: “Service Account Keys, Vertex AI, and the GCP Fortress”,
    “description”: “For regulated verticals, we build isolated GCP projects with service accounts and restricted Vertex AI access. Here’s the compliance architecture for heal”,
    “datePublished”: “2026-03-30”,
    “dateModified”: “2026-04-03”,
    “author”: {
    “@type”: “Person”,
    “name”: “Will Tygart”,
    “url”: “https://tygartmedia.com/about”
    },
    “publisher”: {
    “@type”: “Organization”,
    “name”: “Tygart Media”,
    “url”: “https://tygartmedia.com”,
    “logo”: {
    “@type”: “ImageObject”,
    “url”: “https://tygartmedia.com/wp-content/uploads/tygart-media-logo.png”
    }
    },
    “mainEntityOfPage”: {
    “@type”: “WebPage”,
    “@id”: “https://tygartmedia.com/service-account-keys-vertex-ai-and-the-gcp-fortress/”
    }
    }