BUILD
How We Built DankRank With Claude Code
This build record began before Claude Code was allowed to build the production site.
That was deliberate.
Most “built with AI” stories begin with the finished product and work backward into a clean process. We recorded the decisions, constraints and mistakes while they were happening.
The core site now runs in production on Astro and Cloudflare. Before launch, it went through several implementation and QA passes on protected staging, followed by final production verification after deployment.
That distinction matters. This is a working build record, not a launch announcement.
DankRank didn't begin with Claude Code. I also run ColaDigital, an active digital marketing agency I've operated since 2017. Running it gave me years of exposure to what gets messy when search strategy, delivery, data and tools live in separate places. DankRank is a separate agency and operating model built around how I wanted that work organized now. ColaDigital continues to run. This build record is about DankRank.
- Inputs
- Human search judgment
- AI intelligence
- Purpose-built agents
- Live search data
- Continuous experimentation
Cultivation OS
Human decision + QA
- Outputs
- Research
- Compare
- Test
- Review
- Learn
01
The First Claude Code Test Was Compliance, Not Design
Before we let Claude build the site, I wanted to know whether it would follow the rules when the correct action was to stop.
We gave it the project instructions, governance manifest, decision register and the Step 40 workbook controlling page ownership, metadata, keyword strategy and copy QA. Then we asked it to work inside those boundaries.
Claude stopped instead of building.
Giving a coding tool everything it needs and then judging it by what it refuses to do might sound backwards. For me, that was the point. Generating components is easy. Respecting a decision it has no authority to reopen is much harder, and far more important on a site with this many connected pages.
If it couldn’t demonstrate that restraint before the build began, I wasn’t prepared to trust it with forty-seven pages.
02
We Decided What Every Page Was For Before We Built It
The architecture wasn’t handed to Claude as a loose sitemap with permission to improve it.
Each governed page had a job before production code began. Where search demand applied, the page also had a primary keyword, supporting demand, exclusions, H1, metadata, internal-link ownership and a cannibalization check.
That kept implementation from deciding whether the homepage should own “AI SEO agency” or whether the AI Search page should own “AI SEO services.” Those are search-strategy decisions.
Claude’s job was to preserve them in the build.
03
The Copy Is Locked Before the Build
This is the part that makes the process feel slower at the start and faster later.
We finished the production copy before Claude received permission to build the production pages.
That prevents a common AI-build problem where structure, components and copy all move at the same time. One prompt changes a section. Another changes a component. A third quietly rewrites a CTA. By the time the site is close to finished, nobody knows which artifact is authoritative.
Our sequence is explicit:
Step 40: finish and lock production copyStep 41: run sitewide copy QAStep 42: create the Claude Code Master Build SpecificationStep 42A: run the final Pre-Code GO / NO-GOThen: authorize controlled production implementation
The build is downstream of those decisions.
- Step 40
- Step 41
- Step 42
- Step 42A
04
Claude Code Received a Build Specification, Not a Creative Brief
The Master Build Specification told Claude what to implement and what it wasn’t allowed to reinterpret.
That included the architecture, navigation, design rules, components, schema, metadata, internal links, accessibility, performance, assets, content sources, release controls and the records that replaced older decisions.
When something important was missing or two governance records conflicted, Claude was expected to stop and report it. That happened more than once.
The specification gave us speed inside clear boundaries. It didn’t eliminate mistakes, and it didn’t replace review.
05
The Technical Stack Is Part of the Record, Not the Pitch
The site was built with Claude Code, Astro and Cloudflare. The repository also contains the checks and governance records used to control the work.
Those names make the build easier to inspect. They aren’t the reason to hire DankRank.
The more important question is whether the site preserves its search ownership, works across devices, stays accessible and can be changed without quietly breaking decisions elsewhere.
06
What the Build Exposed
The build didn’t move in a straight line.
Review caught motion that played before visitors reached it, graphics that were too small or too weak, internal pages without enough visual support, navigation that hid useful destinations and QA checks that could pass without testing the experience we actually cared about.
Some instructions were misunderstood. Old governance records caused confusion. A few reports called a pass complete while meaningful review was still outstanding.
Those aren’t side notes. They’re part of the evidence.
The controls became more specific because the mistakes were specific. Motion QA began modelling a visitor rather than a page load. Visual review expanded across routes and screen widths. Records were corrected when measured counts didn’t match what the site actually contained.
07
AI Can Be Fast Without Rewriting the Strategy
Claude Code saves time on the parts of a large build that should be repeatable. It can assemble components, connect structured content, inspect files and run checks much faster than I could manage every page by hand.
I’m happy to take that speed. The problem starts when implementation convenience begins changing decisions that were already made.
Claude may find a cleaner way to build a component or suggest shortening a page. Sometimes the suggestion is useful. Sometimes it removes proof, weakens the page’s search ownership or strips out something the visitor needs to make a decision. In those cases, the faster change is still the wrong change.
The governance gives us a practical way to tell the difference and keeps implementation from quietly taking control of the strategy.
I explain why those decisions still require human ownership in Why Human Judgment Still Runs AI-Native Search.
08
We’ll Publish the Mistakes Too
Claude got things wrong during this build. So did I.
Some decisions that made sense in a document or repository didn’t hold up once the site was running in a browser. I want those corrections to remain part of the record because they reveal more about the process than a cleaned-up story where every decision appears to have worked the first time.
When something fails, we explain what went wrong, how we noticed it and what changed afterward. If the mistake exposes a weakness in the process, the control should improve before the same problem reaches another page.
I’m not interested in rewriting the build history to make working with AI look easier or cleaner than it was.
09
Machine Discovery Is Part of the Build QA
Technical SEO now includes another practical question: can search engines and AI systems access the material we expect them to find?
The build includes controls for crawler access, robots directives and machine-readable files. Those controls still have to be checked against the deployed production site after launch.
DankRank also publishes an llms.txt file. Its presence doesn’t prove that an AI system discovered, understood or cited the site. We need observed evidence before making that claim.
10
Current Build Status
DankRank is live in production.
The core site has been built, reviewed, independently verified and deployed. The current production release was closed on September 10, 2026 after final launch verification of the live site, forms, lead handling, deployment identity and recovery path.
This record will continue to document meaningful changes to how DankRank is built, measured and governed. Public updates will focus on useful milestones, methods, decisions and verified outcomes rather than internal debugging or implementation chronology.