Running a network of small sites from one studio

Business · 2026-06-09 · 9 min read · 1957 words

By ESPYCRUX, Studio

ESPYCRUX publishes five properties — some on subdomains, one on its own domain, one unfinished. It also holds sixteen hostnames, and the gap between those two numbers is the actual subject of this article: what a subdomain costs you that a separate domain does not, and the part nobody warns you about, which is that starting is free and finishing is not.

Most advice about running several web properties is written by people running one. It tends to assume a decision was made — a considered choice between subdomains and separate domains, weighed against SEO consequences and brand architecture.

Our structure was not decided. It accumulated. That is worth saying at the start, because the useful lessons are in the difference between how it happened and how we would do it now.

What the network actually is

Three live things, three unfinished, and one obvious inconsistency: why does the tools site sit on its own domain when everything else is a subdomain?

There is a second, less comfortable number, and it belongs in this article more than the first one does. Those addresses are not all we have held. Counted honestly, the account has carried sixteen hostnames. Ten of them are not on the list above, and this article is largely about why.

The honest answer to the inconsistency

Because it arrived that way.

Smart Tools Today was built by Gagan Sahu, who joined the studio after it had already started. The site came with him — already built, already on its own domain, already with people using it. There was never a moment where someone weighed tools.espycrux.com against smarttoolstoday.com and chose. The choice had been made by circumstance before the question came up.

We could have migrated it. We decided not to, and the reasoning is worth spelling out because it generalises: a working site with existing traffic is a bad thing to move for tidiness. A domain migration risks every link anyone has made to it, resets whatever reputation the domain has accumulated, and produces months of redirect maintenance — all to make an org chart look neater. The inconsistency costs nothing that a migration would not cost more.

The version of this article that pretended it was strategy would be less useful. If your network looks slightly incoherent because of how it grew, that is normal, and it is usually cheaper to explain than to fix.

What a subdomain actually gets you

The subdomain-versus-domain debate is usually argued on SEO grounds, mostly badly. Here is the part that has a concrete, checkable answer.

Advertising inherits down a domain, not across domains. In AdSense, sites are managed at the top-level domain. Subdomains of a verified site are covered by the parent's entry — they were removed from the sites list precisely because they are not managed separately. So an approved espycrux.com covers game.espycrux.com and iblog.espycrux.com without separate applications.

smarttoolstoday.com inherits none of that. It is a separate top-level domain, so it needs its own entry, its own review, and its own ads.txt file. The root domain's ads.txt covers its subdomains when they use the same publisher ID; a different domain is simply a different site.

That is the single most practical difference, and if we had known it at the point the network formed, it would have been an argument for the subdomain — not a decisive one, but a real one.

But approval is not protection. The thing worth understanding, which is the opposite of what most people assume, is that a shared account is shared liability. Policy enforcement happens per URL, but consequences land on the account. A subdomain that breaks the rules can take down the parent and every sibling with it. The parent domain is not an umbrella the children shelter under; it is a rope they are all tied to.

We think about the network that way now. Adding a property is not free even when hosting is free, because every property you attach can affect all the others.

Sixteen hostnames, five properties

This is the part we would have quietly left out of an earlier draft, and it is the most useful thing in the article.

Six properties are published above. The account has carried sixteen hostnames. The difference is made up of a second blog that duplicated the first, a second showcase subdomain, a portfolio, a study-notes site, a shop, a staging copy that outlived its purpose, a shared services layer never meant for visitors, and two temporary addresses left over from a domain change. Some had a real idea behind them. None had a second month of attention.

None of that was a decision either. Each one is the same five minutes: an idea, a subdomain, a one-click install, and then the part that needs a month of attention never arriving. Creating a site is the cheapest action available in a hosting panel, and cheap actions accumulate silently — nothing bills you for an empty install, nothing reminds you it is there, and the dashboard row looks exactly like the rows for the properties that work.

It stays invisible until something makes you count. For us it was an advertising review — every one of those hostnames resolves publicly, and an empty install is a page with no content on it, which is precisely what a reviewer is looking for. The parent domain being good is not the question when the rope ties everything together.

So: audit by hostname, not by intention. Once a year, list every address the account actually serves, not the ones you think of as projects. For each, ask one question — can a stranger who lands here tell what it is? If the answer is no, it should be closed, password-protected, or told not to be indexed, and it should be done that day rather than added to a list. Deleting an unstarted project feels like admitting something. Leaving it up is the more expensive form of the same admission.

We have five properties and eleven reminders that starting is not the hard part.

The hardest part is not the hosting

If you had asked me before starting what would be difficult about running several properties at once, I would have guessed infrastructure. Deployments, certificates, uptime, keeping things patched.

That is not it. Those problems are largely solved and mostly automatable.

The hard part is planning and architecting each one. Every property needs its own answer to a long list of questions that do not transfer: who is it for, what does it do that the others do not, how do people find it, what does its navigation look like, what happens when it is finished, what happens when nobody uses it. A games hub and a tools site have almost nothing structurally in common. The work you did designing one buys you very little on the next.

That cost is per-property and it does not fall with experience nearly as much as you would hope. Six properties is not six times one property in server terms — it is close to six times one property in thinking terms, and thinking is the scarce resource in a small studio. The ten abandoned hostnames are what happens when you pay the server cost and never pay the thinking one.

The practical consequence: be much more reluctant to start another property than another feature. A feature inherits its context. A property has none.

Keeping one identity across several addresses

A network only reads as a network if a visitor can tell. Otherwise it is a handful of unrelated sites that happen to be owned by the same people.

What we found matters, roughly in order:

A single place that lists everything. The main site names every property, what it is, its address, and whether it works. If someone finds the games hub first, one click tells them the rest exists. Without that, each property is an island.

Consistent honesty about status. Three of the six properties appear on the main site with no link, marked in development, because a roadmap you can see is more useful than a roadmap you cannot. The games hub says the games are desktop-only, because they are — the mobile work is real and not done. Being accurate about the unfinished parts is what makes the claims about the finished parts worth believing.

Not forcing visual uniformity. The properties do not look identical and should not. A game hub wants dark, saturated and playful; a tools site wants fast, plain and out of the way. Shared name, shared voice, shared honesty — not shared stylesheet. Trying to impose one design system across genuinely different products makes all of them slightly wrong.

Running the week

Six properties across a small team means the constraint is attention, not capacity. A few things that hold it together, none of them clever:

Batch by property, not by task. Switching between a game hub and a tools site costs more than switching between two tasks inside either. A day on one property gets more done than three days split across three.

Most properties should be quiet most of the time. A live site that needs weekly attention is a liability at this scale. The ones that work are the ones that keep working while ignored — which is an argument for narrow scope, static output and few moving parts, and against anything that has to be watched.

Meetings only where a decision needs more than one person. New tools come out of discussion, and that discussion is worth having properly. Status updates are not, and can be read.

Write things down at the point of decision. With several properties, you will return to something six months later with no memory of why it is the way it is. The reason the tools site has its own domain is a fact worth having recorded — as this article now does.

What we would do differently

Decide the address before building. Not because subdomain-versus-domain is momentous, but because it is nearly free to decide up front and expensive to change afterwards. Anything that is clearly part of the network should start on a subdomain; anything intended to stand alone, possibly to be sold or spun out, should start on its own domain.

Define what "part of the network" means earlier. We had properties before we had a network, and the main site spent a while as a landing page rather than an index. If a visitor cannot tell from any property that the others exist, you have several sites, not a network.

Start fewer things. The clearest lesson, and the one we have the most evidence for. Six properties is already more than a small studio should comfortably run, and the constraint is not money or servers — it is that each one needs someone to think about it. Ten further hostnames started and abandoned is not an embarrassing footnote to that lesson; it is the lesson, written out at full length.

Close things deliberately. The counterpart nobody puts in the advice. A project you have stopped working on is not neutral — it is a page with your name on it and nothing behind it. Closing it is a five-minute job that never feels urgent and never stops being worth doing.

The three unfinished properties on our list stay visible, unlinked and labelled, because a roadmap item you can see is more useful than one you cannot. That is a different thing from an address left running by accident, and the difference is whether anyone would be glad to have found it. The ones nobody would be glad to have found are the ones being closed.

The ESPYCRUX network: espycrux.com, game.espycrux.com, iblog.espycrux.com, smarttoolstoday.com, and three more — a storefront, a forum and a showcase — that are not finished.

Tags: network, subdomains, small teams

ESPYCRUX — ESPYCRUX is a small product studio based in India, building focused web applications and writing about the engineering behind them. Articles are written by whoever did the work, and published under the studio name. Reach the studio at admin@espycrux.com.