How to Monetize a Domain Portfolio: Ten Domains, Ten Businesses, One Repo

Ten domains sitting in a registrar account cost me real money every year and returned nothing. The advice I found for fixing that came in two flavors. Park them and collect ad clicks, or list them and wait for a buyer. Both treat a domain as an asset you are storing. Neither treats it as a business you could already be running.

So in August I stopped storing them. I built one repository that runs ten sites. Six are live right now, each with a paid product wired in from the first deploy, and all ten get a fresh blog post every weekday. The repo started on August 8. As of this week it has taken 110 commits, and the daily routine has published 85 posts across the ten sites, ten a day in a single commit.

That last part is the whole difference, and it is the part the usual advice never reaches. Everyone tells you to build a small site on it in one bullet and moves on. Nobody tells you what happens in week three, when you own ten sites and you are one person.

Why parking and flipping are the only two answers you ever get

Park and flip are the answers that have a vendor behind them. Parking is sold by parking networks. Flipping is sold by marketplaces and brokers. Both are real, both work at scale for people who buy at volume, and both are easy to write a guide about because the entire workflow is: point the nameservers, wait.

Building is harder to sell because it has no vendor. There is no checkout button for turning a domain into a business. So the guides that mention it give it a paragraph, say something about affiliate content and niche sites, and go back to the click-through rates.

The gap that leaves is enormous. Parking pays you for traffic you did not earn, on a page nobody wants to be on. A domain with a real product on it earns from the first buyer and keeps the asset. And the objection to building has never been whether it works. It is that ten sites means ten codebases, ten deploy setups, ten content backlogs, and ten things to forget about. That is a labor problem, and labor problems have engineering answers.

Every domain is a business, not a blog

The rule I run the whole portfolio on is that each site sells something on the day it goes live. Not eventually, not after it gets traffic. On day one.

That sounds aggressive until you see how small the something can be. A featured listing on a directory. A verified certificate. A Pro licence that removes a limit. A single physical product. In my network, one site sells featured placement in a legal AI directory, another sells verified typing certificates, three sell a Pro tier on a small tool. None of these are venture businesses. All of them are real ones.

Building it this way changes what the blog is for. On a parked or content-only domain the traffic has nowhere to go, so you monetize it with ads, which means you need volume, which means most domains never clear the bar. When the traffic has a product to land on, a hundred visitors a month is not a failure. It is a funnel with a small top.

It also changes what a bad domain costs you. If a site does not work, you have lost a folder and some blog posts, not a business you spent three months on.

How to monetize a domain portfolio from one repo

Here is the actual structure. Three pieces do almost all the work.

The manifest is the whole trick

There is one file in the repo that lists every site: its domain, its business type, its product, its keyword themes, and whether it is live yet. Every automation reads that file and nothing else.

This is the difference between managing ten sites and managing one system. The daily blog routine does not know about my sites, it knows about the manifest. The indexing sweep does not know about my sites, it knows about the manifest. When I add a domain, I add one entry, and the new site gets its daily post and its indexing sweep the same week, with no other change anywhere.

Most people build the sites first and the automation later, per site, and end up with ten slightly different scripts. Build the manifest first and the automation gets written once.

Three skeletons cover almost every domain you own

I stopped trying to make each site special. There are three business types in the repo: a paid directory, a paid tool with a licence, and a storefront. Adding a site means copying the closest skeleton, filling in a short spec, and adding the manifest entry.

Sharing one build standard across all of them is what makes the copy step cheap. Same framework, same deploy target, same conventions for where content lives. On the hosting side this is a normal monorepo setup, where each project points at a different directory in the same repository, which is exactly the pattern Vercel documents for monorepos, including skipping builds for projects a commit did not touch.

The temptation is to redesign each site so it feels custom. Resist it. Ten sites that look like siblings and ship in a day each will beat three bespoke sites that never launch.

One payment link per site, wired on day one

Every skeleton ships with a place for a checkout link, and I fill it before the site goes live. For most of these there is no billing code at all. A Stripe payment link is a hosted page you create in the dashboard, share anywhere, and reuse, with receipts and refunds handled for you. That is enough for a featured listing or a one-off certificate. Subscriptions get the same treatment when the product needs one.

The reason to wire it on day one is not the revenue. It is that a site with no checkout quietly turns into a blog, and then you are back to needing ad volume. Put the link in before you have traffic and the site keeps its identity.

The part everyone skips: what keeps ten sites alive after launch week

Launching ten sites is a weekend problem. Keeping ten sites alive is the actual business, and it is where portfolio plays normally die. Three routines carry mine.

The daily blog routine. Every weekday it reads the manifest, picks the next topic from each eligible site's content calendar, researches what currently ranks for that topic, writes the post, generates the image, updates the sitemap, and pushes everything in one commit. Ten posts, one run, no per-site attention. I wrote up the single-blog version of this loop in detail in how I publish a ranking post every weekday, and the network version is that same loop with the manifest wrapped around it.

The weekly indexing sweep. New posts do not get indexed reliably on their own, and ten sites means ten sitemaps that all have to stay current. Google is explicit that a sitemap is a hint rather than a guarantee, and that it must list canonical, absolute URLs. So the sweep regenerates each sitemap, submits it, and requests indexing for anything published since the last run. The reporting half of that habit, reading what actually landed and letting it choose next week's topics, is in the weekly loop that decides what I publish next.

The calendar refill. Each site holds roughly thirty days of planned topics. When a calendar runs low, a separate routine researches the site's niche and refills it. Without this, the daily routine runs dry on the site you were least paying attention to, which is always the one that needed the posts most.

Those three are the moat, not the sites. Anyone can register domains. Very few people will still be publishing on all ten of them in month four.

What this actually costs to run

Honestly: a coding agent subscription, free-tier hosting, and the domain renewals I was already paying. There are no per-article content fees and no content platform. Payment processing costs nothing until something sells.

The real cost is the launch checklist, and it is the item most people underestimate. Each site needs its domain pointed, its analytics connected, its search console property verified, its payment link created, and half a dozen dashboard settings that live outside the repo. I keep a sixteen step checklist for exactly this reason, because the things that break a launch are almost never code. I wrote about that category of failure in the six things that do not travel with your code, and running ten sites multiplies every one of them.

What breaks

I would rather say this plainly than sell you a clean version.

Four of my ten sites are still in the launch queue rather than live, because the checklist takes a real hour per site and I have done six of them. The daily routine has produced posts I have had to go back and fix, usually voice problems, which get solved by adding the pattern to a banned list rather than by editing posts one at a time. And a shared build standard means a bad shared change hits ten sites at once, which has happened, and is the argument for keeping the shared layer small.

None of that changes the arithmetic. Six small businesses running on domains that were costing me renewal fees and returning zero is a better position than ten parked pages, and the marginal cost of the seventh is now an hour.

How to start with two domains this week

You do not need ten. Two is enough to prove the point, because two is where the manifest starts paying for itself.

1. Pick two domains you already own and write one sentence for each: who it serves and what it sells.

2. Choose the closest business type for each. Directory, tool with a paid tier, or storefront.

3. Build the first one, and as you build it, pull every site-specific value into a spec file rather than hard-coding it.

4. Copy it for the second one. This is the step that tells you whether your structure is right. If copying takes more than an hour, the first site is too special.

5. Create both checkout links before either site goes live.

6. Write the manifest, then point one content routine at it. Not two routines. One, reading the file.

If step four hurts, that is the lesson, and it is much cheaper to learn on site two than on site seven.

Get the whole factory on Saturday

I am handing over the entire thing in a live session on Saturday, August 22 at 10 AM Eastern: Domain Factory: One Repo, 10 Sites, 10 Stripe Businesses. You get the monorepo, the three business skeletons, the manifest, both routines, the sixteen step launch checklist, and the kickoff prompts. We add a domain from the audience live and run the checklist on it. The replay and the kit go to everyone who registers.

It is also included, along with every past session and the vault of apps, tools and agents, in the Reinventing AI Accelerator. If you are going to do more than one of these builds, the membership is the cheaper way in. Either way, come with a domain in mind.

Frequently asked questions

Is domain parking still worth it?

For a large portfolio of high-traffic type-in names, parking still earns. For the ten to fifty domains most people are actually sitting on, it earns close to nothing, because parking revenue is a function of traffic you did not create and those names have none. The honest comparison is not parking against building. It is parking against a site that sells one thing to a hundred visitors a month.

How many domains do I need for this to be worth it?

Two. The structure pays off the moment you build a second site from the same skeleton, because that is when the shared build standard, the manifest and the content routine start serving more than one thing. Beyond that the cost per site keeps falling, but the shape does not change.

Do I need to be a developer?

You need to be able to run a coding agent and follow a checklist. The skeletons and the kickoff prompts do the scaffolding, and the launch checklist tells you which buttons to press in the hosting, payment and search dashboards. The genuinely manual parts are the dashboard steps, and those are clicking, not coding.

How long does it take to launch one site?

For me now, about an hour of real attention: fill the spec, copy the skeleton, create the checkout link, and work through the launch checklist. The first one took considerably longer, because the first one is where you are actually designing the skeleton rather than using it.

Will ten auto-published blogs get penalized as spam?

The risk is real, and it comes from thin, unedited output rather than from automation itself. What keeps mine out of that bucket is that each post researches the current top results for its keyword before writing, cites named sources, and runs against a shared voice standard with a banned phrase list. When something slips through, the pattern goes on the list rather than getting fixed post by post.

What happens to a site that never gets traffic?

You leave it running. That is the advantage of the low marginal cost: a site that does not work has consumed a folder, a checkout link, and some posts that keep accumulating quietly. There is no month where you have to decide whether to kill it. If it eventually earns, the product was already there waiting.