The strategy was never the problem. The build was.
For years, I could design the architecture for a data-driven reference site, map intent across hundreds of page types, and build content systems that earn their place in search. But I couldn’t write the build script to generate the pages. I could audit structured data but couldn’t fix the JSON-LD template myself. The bottleneck was never strategy. It was the gap between knowing what to build and being able to build it.
That changed when I started using AI not as a content generator, but as an execution layer for the systems I already knew how to design. Not “write me a blog post.” More like “build a pipeline that reads NEC electrical code data, applies this template logic, and generates pages for every wire gauge, every appliance, every state, with derating calculations and inspection guidance baked in.”
The result is four live sites, each one built around real data, real expertise, and the kind of depth that makes it genuinely useful to the person who lands on it. This page explains the system behind all of them.
The System
Most people use AI as one tool that thinks, builds, and remembers all at once. This system works because it keeps those three things separate.
This is where I decide what pages should exist, what intent type each one serves, how they connect to each other, and whether they earn their place by providing something genuinely useful that doesn’t already exist. The thinking layer evaluates hypotheses, maps competitive gaps, and stress-tests architecture before a single page gets built.
CheckMyTap’s architecture wasn’t generated. It was designed through weeks of research into how people actually search for water safety, where existing resources leave them confused, and what data exists in government records that nobody had structured for regular homeowners. AI helped me stress-test the hierarchy and identify gaps. The strategic decisions about what pages to build, what data to surface, and how to connect city reports to treatment recommendations were mine.
The execution layer follows established architecture. It writes build scripts, generates pages from structured data, implements markup, runs pre-deployment audits, and deploys. It does not make strategic decisions. The rule: if execution requires a new architectural decision, stop and return to the thinking layer.
WireRef has hundreds of pages: ampacity tables for every standard wire gauge, 48 appliance wiring guides, 50-state electrical code profiles with compliance scoring, interactive calculators for voltage drop and panel loads, and 35 project wiring guides. All generated from structured NEC data through a single build pipeline. One template improvement propagates across every page type simultaneously. AI built the pipeline. The decisions about what an electrician actually needs to see first, how state code variations should be surfaced, and where the derating walkthrough belongs on each page came from the thinking layer.
Every project has documented architecture, known mistakes to avoid, and standards that carry forward. The tools read this context at the start of every work session, so each session picks up where the last one left off with the full weight of every previous decision behind it.
A deployment mistake on CheckMyTap (dynamic dates in schema markup that regenerated on every build) became a documented rule. That rule was already in place before WireRef’s first deploy. It will be in place for every future project. The system doesn’t forget.
The separation is the point. Thinking, execution, and memory each fail in different ways. When they’re collapsed into one workflow, strategic shortcuts creep into implementation, and hard-won lessons from past projects don’t carry forward. Keeping them distinct is what makes the output reliable enough to put in front of real people.
But the real advantage is what happens over time.
Every project teaches the next one something. Architectural patterns that work get documented and reused. Mistakes get captured so they never repeat. Decision frameworks get refined based on what actually happened, not what was predicted. Each new site builds faster and cleaner than the last, not because the tools improved, but because the knowledge behind them compounded. I designed the system specifically so that learning accumulates rather than resets. My SEO decision log is the public-facing version of this principle in action.
Where The Advantage Actually Lives
That compounding knowledge matters because everything else about this system is accessible to anyone. The tools are available. The architecture pattern is on this page. So where does the actual advantage come from?
These are production sites with structured data, affiliate compliance, multi-language support, accessibility standards, and pre-deployment audit systems. They’re built to last and maintained over time.
The data comes from NEC tables, EPA records, AWS specifications. AI builds the infrastructure that organizes and serves it. It doesn’t write the recommendations or invent the numbers.
Every strategic decision goes through human evaluation based on how search systems actually interpret content.
So if it’s not about the tools or the automation, what is it about?
The moat is three things working together.
Proprietary data structures
WireRef assembled 50-state NEC adoption data with compliance scoring, pre-computed derating tables for every wire gauge, and inspection guidance that nobody else has compiled into one reference. CheckMyTap turned fragmented government water quality records into city-level reports with hardness comparisons, contaminant context, and treatment recommendations. GageRef organized welding specifications into comparison frameworks welders actually need on the job. The raw data is public. The way it’s structured and connected to serve real questions is not.
Accumulated architectural knowledge
Eight years of understanding how search works applied to every template, every internal link, and every schema decision. Pages designed around how people actually look things up, with structures that both traditional search and AI systems can understand and reference.
The compounding system
Every project makes the next one better. Mistakes become rules. Patterns become reusable templates. After four sites and hundreds of documented decisions, the distance between someone starting fresh with the same tools and this system doesn’t close with better AI. It widens.
AI makes everyone faster. Domain expertise determines whether that speed produces something durable or something disposable.
The Proof
Here’s what that system produces. Four sites, all live, all built from zero.
What I Learned
Four principles that emerged from building these sites. Not theory. Residue from shipping.
“Better files, not better prompts.”
Providing AI with rich context about the project, the architecture, the standards, and the mistakes to avoid produces better output than clever prompting. The quality of what you feed in determines the quality of what comes out.
“Fix source files, never generated output.”
The JSON data and templates are the truth. The HTML pages are the output. Every fix happens upstream so it propagates everywhere. This is how one change improves a thousand pages.
“Finished in a small area before expanding.”
A site with 69 polished, data-rich pages that a welder can actually use is worth more than 200 half-built ones. Resist the urge to build wide and shallow. Depth earns trust from both users and search systems.
“Every mistake becomes a rule.”
The first deployment had dynamic dates in schema markup that regenerated on every build. That became a documented rule before the second site launched. The system is built to accumulate lessons, not repeat them.
This is a living system. The sites are being iterated on. The principles are being tested. I’ll be writing more about specific aspects as patterns emerge across content strategy and modern search.
Go Deeper
Posts where I dig into the ideas behind this work.