For years, my biggest problem wasn’t code.

It wasn’t design.

It wasn’t even the product.

It was distribution.

I could ship a startup in 10 hours. I could lock myself in a room for 35 days and build authentication, payments, SEO, email infrastructure, and everything in between from scratch.

But none of that mattered if nobody saw what I built.

I learned that lesson the hard way with SuperFast.

I launched it on May 4, 2025.

My first paying customer arrived on July 30.

Eighty-seven days of silence.

The product worked.

Distribution didn’t.

The Tweet That Changed Everything

On December 24, 2025, I posted a tweet about programmatic SEO.

It exploded.

More than 800,000 views.

The post made its way into Twitter’s global news feed and introduced me to an audience I had never reached before.

Three days later, I launched SEOitis as part of a 12-hour startup challenge.

The launch video crossed 350,000 views.

I made my first dollar before midnight.

But the viral tweet wasn’t the real breakthrough.

The real breakthrough was what happened after.

I stopped treating distribution like luck and started treating it like a product.

SEOitis: Distribution on Autopilot

SEOitis isn’t just an SEO tool.

It’s an autonomous content engine.

You paste your website URL.

SEOitis crawls your business, researches keywords, generates content in your brand voice, adds internal links, creates FAQ schema, updates llms.txt, scores quality, and publishes directly to your CMS.

Eight stages.

Fully automated.

Nothing below an 85/100 quality score gets published.

I built it because I was tired of manually writing blog posts while trying to run multiple startups.

Distribution shouldn’t consume your entire week.

The results were immediate:

My own websites started ranking without me touching a keyboard.

Users began paying $49/month for AEO and GEO features that help them rank inside ChatGPT, Perplexity, and other AI search systems.

The product started selling while I slept because the problem was obvious: everyone wants traffic, but very few people want to spend hours creating content.

SEOitis eventually became the distribution engine behind everything else I build.

Not social media.

Not cold outreach.

Compounding search traffic.

$4,000 Per Month: How the Stack Adds Up

By January 2026, I crossed $4,500 in monthly revenue.

Today, the business generates roughly $4,000 per month consistently.

Not because of one lucky launch.

Not because of one viral tweet.

Because of stacked systems.

Revenue comes from:

SEOitis subscriptions

SuperFast lifetime and recurring plans

MakeItLast purchases

ScrollLaunch premium launch packages

Affiliate and content income

The pattern is always the same:

Build something useful.

Automate the repetitive parts.

Let distribution work in the background.

How I Automated My Startups

Here’s what automation looks like across my products.

1. SEOitis — Content Distribution

Keyword research, content briefs, article generation, rewrites, internal linking, metadata, schema generation, quality scoring, and publishing.

Everything runs automatically.

A complete article takes 60 to 120 seconds.

I don’t write blog posts anymore.

The system does.

1. ScrollLaunch — Launch Distribution

ScrollLaunch is a launch platform for indie makers.

Founders submit products, climb weekly rankings, earn high-authority backlinks, and get discovered by builders, search engines, and AI systems.

The entire weekly cycle runs automatically.

Submissions, voting, rankings, and directory listings happen without manual intervention.

1. MakeItLast — Accountability Distribution

MakeItLast combines public accountability with progress tracking.

Users connect Stripe, Dodo Payments, Polar, or Lemon Squeezy, and their revenue updates automatically on a public profile.

I built it because attention without direction is noise.

Public accountability turns attention into action.

1. SuperFast — Shipping Distribution

SuperFast is the foundation behind every startup I launch.

Authentication, payments, SEO, email infrastructure, legal pages, and everything required to launch quickly are already built.

Instead of rebuilding infrastructure every time, I focus on distribution and customer problems.

Four products.

Four layers.

Content.

Launches.

Accountability.

Speed.

That’s the system.

What Cracking Distribution Actually Means

Most founders think distribution means going viral.

It doesn’t.

Distribution means building systems that consistently put your product in front of the right people.

For me, that required three major shifts.

1. Stop Building in Silence

Building in public created the first wave of momentum.

The tweets.

The launch videos.

The daily updates.

But momentum eventually fades.

1. Build Distribution Into the Product

SEOitis publishes content.

ScrollLaunch promotes launches.

MakeItLast makes progress visible.

The products distribute themselves.

1. Automate Everything That Repeats

Keyword research.

Content creation.

Revenue tracking.

Launch cycles.

If I found myself doing something manually twice, I automated it the third time.

“Distribution is not a launch-day problem. It’s a system you build and let run.”

What I’d Tell My Past Self

If you’re sitting at zero users right now, here’s what I’d tell you.

1. Your Product Is Probably Fine. Distribution Isn’t.

Stop adding features.

Start getting discovered.

1. One Viral Moment Is Not a Strategy.

Build systems that work when you’re offline.

SEO.

Directories.

Public accountability.

Automated content.

Assets that compound.

1. Automate the Boring Work.

Writing.

Publishing.

Tracking.

Reporting.

Revenue syncing.

Protect your time so you can focus on talking to customers and shipping improvements.

1. Stack Small Products Instead of Chasing One Moonshot.

My income didn’t come from one breakthrough startup.

It came from multiple products working together:

SEOitis

SuperFast

MakeItLast

ScrollLaunch

Content income

Small bets that compound over time.

I’m not special.

I simply stopped treating distribution as something that happens to you and started building it like a product.

If you’re building something today, automate distribution before you automate anything else.

I use Claude Code on my Mac, OpenAI Codex in my terminal, Cursor in VS Code, and Hermes Agent in containers. Each tool is good at something different, but there's a brutal cost: every time I switch, my context resets.

Last week I debugged an auth issue in Claude Code. Figured out the root cause, understood the fix, saved the session with enough detail to reconstruct the reasoning. Wednesday I opened Cursor on the same code. The auth issue was still there. I re-explained it to myself from scratch, made the same wrong turns, wasted 20 minutes rediscovering a conclusion I'd already reached.

That's the tool-switching tax: brilliant insights stay locked in the tool where you had them.

Why Cross-Tool Memory Matters

Every AI coding tool keeps memory isolated by design. Your context doesn't follow you. You carry forward decisions manually, through notes or copy-paste or the optimistic fiction that you'll remember.

The specific costs add up fast. You lose signal continuity -- the breakthrough you had in one environment stays locked there. The next tool doesn't know the problem exists, so you re-discover it, re-research it, re-explain it. You lose time -- every switch costs 5-15 minutes of preamble, reading prior conversation history, re-extracting key decisions, re-framing what you were trying to do. And you lose confidence in what you actually know, because you're never sure if the decision you made in Codex last week still applies to the code you're reviewing in Cursor today.

I tried the manual workflow -- maintaining a running notes file, copying key decisions into a shared doc. It doesn't scale. After jumping between four tools across a full week, you're spending more time explaining context than building.

The alternative is memory tied to your identity, not your tool. One memory store. All your tools can reach it.

What Changed

That auth middleware issue I had in Claude Code? It lives in one place now. Cursor can find it. Hermes Agent can reference it. Codex can pull it up. Same memory, all tools.

Here's a concrete week of what that looks like:

Monday in Claude Code: Debug pipeline timeouts, discover it's worker thread saturation, save the session with tag pipeline-scaling and a note about the specific concurrency threshold that matters.

Tuesday in Cursor: Working the same project on a different feature. Search pipeline-scaling, see Monday's decision, avoid re-discovering the bottleneck before I accidentally make it worse.

Wednesday in Hermes: Spinning up the pipeline in containers. Check the pipeline-scaling decision, configure Docker resource limits based on that prior analysis rather than guessing.

Three tools, one insight, no repetition. The research happened once.

Signal Over Noise

Here's what made the difference: the memory captures automatically, but stays manageable because you control what you do with it.

At the end of every session, a hook fires and saves context without asking. That's the right default -- the decisions you forget to save manually are often the ones you need three weeks later. But automatic capture without curation turns into noise fast. LoreConvo gives you the tools to work the signal out of it: tags, search, session linking, and an inspection interface that lets you review what got saved and prune anything that doesn't hold up.

In practice this means rubber-ducking sessions get captured and ignored. Breakthroughs get tagged and surface immediately when you search. Decisions get timestamped so you know whether they're still current. The result is a vault where searching actually returns something useful, because the curation layer sits on top of automatic capture rather than replacing it.

Where It Lives

All of this sits on my machine in a single SQLite file. No cloud sync, no vendor account, no third-party server that can go down or change its pricing model. The memory is mine. I can back it up, I can export it to JSON, I can delete it whenever I want.

That matters when you're storing decisions about production systems, architecture choices, or anything you'd rather not hand to a cloud provider by default.

The Setup

Install once. Hooks handle the rest. At the end of a Claude Code session, a hook fires and automatically saves context. The CLI lets you search all your sessions from anywhere. The MCP server lets your AI tools query the vault directly when they need to find related context. Tags and search keep the vault navigable as it grows.

Try It

If you're juggling multiple AI coding tools and losing context on every switch, this solves that exact problem. One install, all your tools, one searchable vault of decisions and breakthroughs that follows you wherever you work.

Install LoreConvo and keep your memory portable across every tool in your workflow.

Your tools keep changing. Your memory doesn't have to restart.

The obvious counterargument to everything I'm building is this: Google already does it. You type "best AI tools for video editing" into Google and an AI Overview surfaces a curated list, synthesized from the same kind of data I maintain, without requiring a click. My three directory sites — Top AI Tools, Find Games Like, and Open Alternative To — are competing with a feature baked into the world's dominant search engine.

I launched these sites on 2026-04-23, built on an architecture that runs at about $25/month. Traffic is essentially zero — the sites have been indexed for three weeks and organic crawling takes time. The question I keep returning to isn't whether Google will eventually index my pages. It's whether anyone will prefer clicking through to my site over reading the AI Overview box that already answered the same question.

Here's my honest, falsifiable position.

The bet, stated plainly

By October 2026 — six months post-launch — at least one of the three sites will show organic click trends in Google Search Console indicating real query traffic to specific comparison or filtered-browse pages. I define that as: at least 200 non-homepage organic clicks per month, sustained for two consecutive months, from queries I didn't directly drive through social or newsletter posts.

If that doesn't happen, I'll publish the Search Console screenshots and write a post explaining what I got wrong. I'm committing to that here.

The counterargument I take seriously

AI Overviews have gotten genuinely good at list-and-compare synthesis. If you search "open source alternative to Notion" today, Google often returns a four-item structured list with one-sentence descriptions directly in the Overview box. My Open Alternative To site covers that territory. The AI Overview absorbs the zero-click version of that query.

The optimistic response is: "my site appears as a citation source." The pessimistic response is: "Google consumes your signal and stops sending clicks." The pessimistic version has supporting evidence — industry-wide CTR on informational queries dropped measurably as AI Overviews expanded through 2025, and the trend hasn't reversed.

I don't think the pessimistic version is the whole story, but I'm not dismissing it. The most dangerous move is to assume the counterargument is wrong without designing around it.

Where AI Overviews have structural blind spots

AI Overviews are strong at synthesizing "what exists." They're weaker at three things I've deliberately built for.

Attribute-based filtering. If someone wants "open source Notion alternatives that work offline and have a mobile app," AI Overviews give hedged prose answers because they're synthesizing text, not querying structured fields. My Turso DB has works_offline, has_mobile_app, and last_commit_date as typed columns. Faceted filtering on those fields is something a browseable directory does better than a language model writing a paragraph about the general landscape.

Editorial negative-space. My game recommender includes "avoid if" caveats — structured fields that answer "who should skip this?" generated by a Claude Haiku prompt that specifically forces a critical answer. AI Overviews don't have a mechanism to surface structured negatives. They default to positive framing, which means someone with a specific disqualifying requirement gets an unhelpful answer.

Freshness on maintenance status. The ETL that populates the AI tools directory pulls GitHub commit activity weekly. A tool that hasn't been touched in 14 months is marked as low activity. AI Overviews don't distinguish between a tool actively maintained in 2026 and one that peaked in 2024 — they rely on the recency of web mentions, which can lag by months after a project goes dormant.

None of these defenses are permanent. Google could build structured attribute filtering into AI Overviews. But they require deliberate pipeline design, not just synthesis, and the gap exists now.

The downstream click thesis

Even if my sites lose the zero-click battle on broad discovery terms, there's a second query type I'm explicitly targeting: the downstream comparison query.

The sequence: someone types "Notion alternatives" into Google, gets an AI Overview naming four tools, then types "Appflowy vs Anytype performance" to compare the two they're considering. That second query is post-AI-Overview research. It has commercial intent. It wants a verdict, not another list.

For that query, a page with structured attribute comparison, a clear verdict, and fast load time competes directly with another AI-style answer — and structured data beats generative prose for "which one wins on attribute X." This is partly why I chose static SSG over dynamic AI rendering for these sites: a fast, indexable page with typed comparison fields is what a second-stage research click needs.

The comparison and filtered-browse rows are the actual load-bearing columns of this bet.

Why the cost structure matters for intellectual honesty

At $25/month, I can run this experiment for a year without needing revenue to justify continuing. I'm not under pressure to interpret ambiguous signals optimistically.

Compare that to a project burning $200/month on infrastructure: you'd rationalize flat Search Console data as "still in the sandbox phase" past the point where the data actually says something. The full cost breakdown is genuinely minimal — Vercel Pro at $20, Turso starter at $0, Claude Haiku API in single-digit dollars for monthly ETL runs, GitHub Actions on free minutes.

I won't claim AdSense is approved or revenue is flowing until it is. Right now, AdSense rejected the *.vercel.app version of the sites. I've moved to custom domains and verified them in Search Console. I'm waiting for real crawl data before making any claims about what's working.

What would change my mind

Three outcomes would tell me the bet is wrong:

Impressions but near-zero clicks at 90 days. If Search Console shows my pages appearing as AI Overview citation sources but click rates stay near zero on comparison pages specifically, Google is extracting my signal without distributing traffic. That's the worst-case scenario — I'd need to rethink the format entirely.

AdSense keeps rejecting after genuine depth improvements. The original rejection was partly a *.vercel.app domain issue, but if Google's classifier still rates the pages as thin after I've rebuilt with real structured content and specific editorial attributes, my model of what "quality" means to the classifier is wrong.

Comparison queries migrate fully to LLM chat. If people stop typing "X vs Y" into Google and start asking ChatGPT directly, the downstream click I'm betting on disappears. I don't see evidence of this happening at scale for research involving specific attribute constraints — but I'm monitoring query volume patterns month-over-month.

The first outcome is the one I'd want to see early. Impressions with near-zero clicks on comparison pages by month 3 would tell me to pivot the format immediately rather than wait six months for a conclusion I could have reached sooner.

FAQ

Why three sites instead of one authority site?

Three narrow sites let me test three different intent types simultaneously. Games-like, AI tools, and OSS alternatives attract different queries and different audiences. One site would take longer to produce the same signal volume about which format works. The original architecture post covers the reasoning.

How does Claude Haiku generate the structured editorial fields?

Each ETL run sends entries through a shared Claude Haiku client that uses system-prompt caching to amortize the cost across batch runs. The prompts are tuned to force specific attribute outputs — avoid-if caveats, audience fit, freshness status — not open-ended descriptions.

What if one site works and two don't?

That's a useful outcome, not a failure. The format that works tells me something specific about the intent type. I'll invest in what works and document what didn't.

Where will you publish the October 2026 verdict?

On this blog, with raw Search Console screenshots. I'll publish regardless of whether the numbers are favorable.

Part of an ongoing 6-month experiment running three AI-curated directory sites. The technical claims here are real; this article was AI-assisted.