Execution (5): Marketing and Growth#

When developers found a company, marketing is the thing they push back the furthest. Building is familiar; getting the word out is not. But now that AI lets you build almost anything quickly, “can it be built” has become less scarce, and who gets people to use it matters more. Based on what I learned running this blog and my products, this chapter covers the marketing a developer-founder can do alone. It is not a story of flashy strategy but of systems, measurement, and small experiments.

Content is a system, not an output#

I have started and stopped blogs several times. A translation blog stopped because each page took too long; a prompt-log blog stopped because it got no exposure at all. Looking back, the common cause was deciding “what to write” first without deciding “how to keep producing.” The current blog has lasted because I did it the other way round. The system comes first, not the topic.

That is why I call this blog a “content factory.” Essays, books, apps, and news briefs are all treated as content; the entire production process lives inside the repository; and agents handle the repetitive steps. The factory is made up of four lines.

What the agents do in this structure is concrete. Every week they read multiple sources and draft the news brief, review an essay’s style and format against the quality standards document, generate illustrations, translate into English, and run the pre-build and pre-deploy checks. All of these procedures are pinned down as skills inside the repository, so I start a step just by saying “write this week’s brief” or “review this post.” Overhauling an entire book by myself runs on the same factory.

The yardstick for value is simple too. Is anyone consuming it? And I look at “behavior” rather than “reactions.” Likes and view counts are signals, but light ones. Behaviors like saving, subscribing, returning, asking questions, sending inquiries, and converting to paid are far stronger signals, and when I evaluate content and products, those are what I prioritize.

Search: what a new domain goes through#

It is easy to assume that if you make content, search will deliver readers. My experience was not that simple. About a month after moving the blog’s primary domain, search impressions fell off a cliff from one particular day, dropped to effectively zero, and did not recover for more than ten days. I checked redirects, canonical URL tags, hreflang tags, the sitemap, and internal links; nothing was technically wrong. The search bot was diligently fetching pages while refusing only to put them in the index.

This was not an error. It was a verdict. Search engines are very conservative about what they index from a new domain that has not yet built trust. And my sitemap was badly positioned for that verdict. More than half of the submitted URLs were tag and category pages, thin pages that list nothing but post titles. The pages a static site generator produces automatically for every tag had piled up in two languages. From the search engine’s point of view, this site was “mostly contentless lists,” the worst possible first impression for a new domain.

The response was an index diet: pulling thin pages out of the sitemap and the index to raise the average quality. I put a single verdict rule in the templates so that sitemap exclusion and the noindex meta tag always share the same decision.

Verdict (one rule)
 ├─ Tag · category pages              → exclude all
 ├─ News briefs older than 30 days    → exclude (timeliness expired)
 └─ Frontmatter noindex: true         → escape hatch for manual exclusion
      ↓                    ↓
  Drop from sitemap.xml   Emit <meta name="robots" content="noindex">

As a result, the number of URLs in the sitemap fell by more than half, and the page set submitted to search engines shifted from “mostly tag lists” to “mostly real content.” Recovery was not fast. Repeated indexing requests kept getting rejected, and eventually I had to move to building external signals (profile links, cross-posting on other platforms, registering with other search engines). You have to accept that search traffic for a new domain is a matter of months. In the meantime, what brings readers is not search but direct distribution: communities, newsletters, social.

There is one new variable as well. As more people ask AI instead of searching, becoming content that AI cites in its answers has become a new path to exposure. The rules in this area are not yet settled, but the direction observed so far is not very different from traditional search optimization. Content with a clear source, a clear structure (headings, summaries, tables), and one page that answers one question head-on gets cited. And since every AI service trains on and searches more English material, keeping an English edition alongside widens your reach.

Analytics: which number you look at changes the story#

Ironically, what led me to discover the search problem was a false alarm: a “sharp drop in active users.” The active users graph in the analytics tool fell steeply, and I handed the agent a full investigation. The result was not what I expected. Most of the drop was an illusion.

Three layers of illusion were stacked on top of each other. First, the daily graph showed the return to the mean from an abnormally high peak as if it were a decline. Second, the last value of a week whose aggregation had not finished looked like a crash to the floor. Third, and biggest: nearly half of the active users were not people. Traffic from a particular overseas data-center region had a users-to-sessions-to-pageviews ratio of exactly 1:1:1 and dwell time converging on zero seconds. These were automated crawlers and AI scrapers. Korean traffic, by contrast, viewed several pages per session and stayed more than a minute.

The useful discriminator here was engaged sessions. Because a session only counts if it lasts beyond a certain time, views two or more pages, or triggers a conversion event, bots hardly ever produce them. Viewed through this metric, the picture changed completely: real readership was flat. Active user counts are too easily polluted to serve as a blog’s health metric. A wave of bots arriving and receding is enough to make the graph swing, and the operator ends up reacting to a crisis that does not exist.

Here is the inspection order I distilled from that investigation.

1. Change the period and look again. Check whether a daily drop is still a drop at the 30-day scale.
2. Look at engaged sessions instead of active users. If a country’s users:sessions:pageviews is close to 1:1:1 and its engagement rate is in the single digits, it is bots.
3. Open the search console even when visit metrics look calm. A collapse in search exposure barely shows in the visitor graph.
4. If “Crawled – currently not indexed” is piling up, suspect a quality verdict, not a configuration issue. Open up the sitemap composition.

And the queries I had been writing by hand in every investigation (daily and weekly trends, per-country bot detection, per-section performance) were folded into the analytics skill as official modes. The next time the same symptoms appear, the agent diagnoses straight through the sequence “trend → bot pollution → index.” Analytics in a one-person startup is not about building a dashboard; it is about teaching the agent an analysis procedure.

There was a bonus finding too. More than half of my recent publishing effort had gone into news briefs, but nearly all the new readers were brought in by essays, which were published in far smaller numbers. Search clicks and organic overseas readers both came from essays. This was no reason to stop publishing news, but it did force a redefinition of its role. The configuration the data pointed to was a pipeline in which news serves as a topic sensor that collects material and keeps track of the current, and topics that drew a response get promoted into essays. The execution part of this book is itself a re-bundling of essays that came out of that pipeline.

Ads: small, with AI-made creatives#

Advertising is buying time with money. If a one-person startup runs ads, the goal should be getting a signal quickly, not revenue: seeing within days, rather than waiting months for search to deliver it, which message which kind of person responds to.

What AI changed is the cost of producing creatives. You can make ten pieces of copy that describe the same product from different angles and five banners in different moods in a single day. So the unit of an ad experiment shifts from “carefully craft one campaign” to “throw several hypotheses out at once and watch the response.” The “cast your lines in many places” approach from the idea-discovery chapter applies to advertising too.

Agents enter on the operations side as well. The ad analytics chatbot I build at work chains together querying campaign performance by condition, analyzing causes, and proposing next actions (budget adjustments, target changes, creative tests) in a single flow. The company’s ad operations team projectized its operating guidelines and brand data into a repository and shifted to handling work by conversing with an agent. A one-person startup can start by connecting the ad platform’s API or an MCP server to an agent, with a single skill: “summarize yesterday’s performance and report any outliers.” Actions that actually change the budget, though, go behind a human-approval gate, as discussed in the operations chapter.

Distribution: go where the users already are#

Finally, distribution. Search and ads bring users to my site. The opposite approach is putting my product where users already are, and in the AI era this approach is gaining weight.

The MCP server covered in an earlier chapter is the prime example. Expose your service’s data and functions as an MCP server, and users call your features from inside the agent they spend all day in. Custom chatbots on chat services (GPTs and the like) are a lightweight distribution channel of the same character. Neither brings users to you; both go to where the users are, require no UI to be built, and leave the model cost on the user’s side.

A product that rides on a platform, however, can lose its place when the platform absorbs that function. The browser extension I was building faced exactly that risk with the arrival of AI browsers. So it is better not to bet on a single distribution channel, and to define the product’s core not as “a bundle of extension features” but as “a workflow that standardizes the user’s repetitive tasks”, broken into small modules and templates that can survive at any layer. When the technology layer shifts, the outputs are the first to wobble, but the ability to produce them and the judgment behind them remain.

Checklist#

1. Decide the system before the topic. Pin the topic sensor, production line, distribution line, and learning line as procedures inside the repository.
2. Measure success by behavior (saves, return visits, inquiries, conversions), not reactions.
3. Accept that search traffic for a new domain takes months, and gather readers through direct distribution in the meantime.
4. Pull thin pages out of the sitemap and the index, and make sitemap exclusion and noindex share the same verdict.
5. Look at engaged sessions rather than active users, and open the search console even when visit metrics look calm.
6. Turn analysis procedures into agent skills so the same symptoms get diagnosed immediately.
7. Use ads in small amounts to buy signal, and have AI produce creatives for several hypotheses at once.
8. Put the product where users are through MCP servers and custom chatbots, but do not bet on a single distribution channel.