Distribution Is the Moat - Playbook

The objection you should be asking

If a non-technical founder can ship a real product in 18 days with an AI assistant, then so can everyone else. "I built it with AI" is not a moat. By the time you read this, it is table stakes.

So the real question is not "can you build it?" It is "can anyone find it?" The answer to that is the only durable advantage left, and it has almost nothing to do with the AI that wrote the code. This is the part of the story that separates a product from a weekend project.

The strategy: an SEO flywheel, captured early

The decision that mattered was made before most of the features existed: treat distribution as a system to build, not a thing to bolt on at launch. Concretely, four moves, each captured in a file so it could not drift:

1. Personas, written down in one place. docs/personas.md (the roofer, the realtor, the therapist, the recruiter, and so on): who they are, the exact friction they feel, and the words they actually use. This is the source of truth everything else points at. Capturing personas in a file on day one, before the copy and the landing pages, is what keeps the whole funnel speaking one language.

2. Every feature ships a help article. Not as documentation, as a search-and-discovery surface. A user who Googles "how do I send a quote a customer can sign from their phone" should land on a RadiusOS help page. Today there are roughly 38 of them.

3. Every feature pairs with a search-intent blog post. The slug is the search intent, not the feature name. The HVAC pipeline template does not pair with a blog called "hvac-service"; it pairs with "hvac-lead-generation," because that is what the customer types. The blog is the SEO trapdoor; the product page is where they land after they click. Today there are 20.

4. Every persona gets a landing page that names their pain. /for/[vertical] and /marketplace/[slug], driven by lib/vertical-copy.ts (22 entries): a page per vertical that opens with the specific dollars-and-time pain that persona feels, then shows the product shaped to their workflow. The roofer searching "roofing CRM" lands on a page about forgotten estimates and insurance timelines, not a generic feature grid.

On top of those four: comparison clusters ("X vs Y" search) and a glossary cluster ("what is Z" search), each written with an honest "when the competitor wins" line so the pages are credible rather than spammy.

Why it is believable: it is enforced, not intended

Here is the part that turns a nice idea into a defensible one. The flywheel is wired into the build itself. The repo runs prebuild gates that fail the build when:

a feature flag ships without a matching help article (check-help-articles),
a feature is not mentioned on the pricing or features page or in the docs (check-marketing-coverage),
a marketplace template ships without its landing-page copy (the vertical-copy rule),
a feature card renders without its visual (check-features-have-visuals),
a marketing route is in the sitemap but not reachable (check-sitemap).

You cannot ship a feature here and forget the distribution work, because the deploy will not go out. That is the "convention to miss to gate" principle (Module on scars) pointed straight at growth: the discipline was learned the hard way (Walk & Talk once shipped with zero help and zero marketing coverage), then encoded so it cannot rot. A reader can verify all of this in the repo, which is exactly why it builds belief instead of asking for it.

The flywheel, in one loop

A roofer Googles "roofing lead generation." A search-intent blog post ranks and catches the click. It hands off to the persona landing page that names the roofer's exact pain. They sign up, install the roofing template (preconfigured for their workflow), and start using a feature that has its own help article (more indexed surface area, more entry points). Every feature added widens the funnel, and the build gates guarantee the funnel widens with it. On top of that sit the deliberate growth loops (the AI-draft email footer on free-tier sends, shareable deal-score cards, the public AI-CRM benchmark page) that turn usage into impressions.

The lesson

Building is the cheap part now. If you take one thing from this module: stand up the distribution system before you need it, capture it in files so it speaks one language, and make "ships with a help article, a blog post, and a landing page" a definition of done that your CI enforces. A feature without a way to be found is a feature nobody uses.

The honest caveats

SEO is a compounding bet, not a launch spike. This pays off over months. The flywheel is built early precisely because the payoff is late.
Distribution does not save a product that does not work. This sits on top of a real product with a real workflow, not instead of one.
Volume is not quality. 38 articles and 20 blogs only matter if they are honest and useful (Principle #7). Spammy SEO content built fast with AI is its own failure mode; the gates check presence, your judgment checks quality.

Exercise

Write your personas.md first: 3 to 5 personas, each with their pain in their own words.
Pick your first feature. Write its help article and its search-intent blog post in the same change that ships the feature.
Build one persona landing page that opens with that persona's specific pain.
Add one CI check that fails your build if a new feature flag has no help article. Now the system enforces itself.

Distribution, the Real Moat