The URL map: naming, routing, and interlinking a multi-product ecosystem

A multi-product ecosystem lives or dies on whether people — and search engines — can navigate it, and that navigability is not a happy accident but a deliberate structure of domains, paths, and links. As soon as you have more than one product, you face decisions about where each one lives, how its URLs are named, and how the properties reference each other, and getting those decisions wrong produces an ecosystem that feels like a scattered collection of unrelated sites rather than a coherent whole. This post lays out the URL map for the Novus ecosystem: the hub-and-spoke domain layout, the naming logic that keeps it predictable, and the internal-linking strategy that ties it together. It is a deeper look at the structure the quick-start URL orientation introduces.

The organizing principle is hub-and-spoke, and it applies to the URL structure as directly as it applies to the code. There is one hub that owns the ecosystem's narrative, reference, and navigation, and there are product spokes that own the actual applications. Every decision about where something lives and how it is named flows from that one structural idea, which is what keeps the map coherent as it grows rather than accreting into a tangle.

The top-level structure is a single hub domain with product spokes on their own subdomains. The hub, at the root domain, is where the ecosystem explains itself: the portfolio, the ventures overview, the documentation, the product blog, the changelog — everything whose job is to describe, reference, and route. The products live on subdomains of that same root — the background remover and the visualizer each on their own subdomain — because they are distinct applications that benefit from their own address while still being clearly part of the same family through the shared parent domain. A visitor seeing a subdomain of the hub immediately understands they are still within the Novus ecosystem, which a wholly separate domain would not convey.

This layout does specific work. It keeps the hub as the single front door — the one address to remember, from which everything else is reachable — while giving each product the dedicated space an application needs. It signals the relationship between the properties through the domain structure itself: the shared root says "same ecosystem," the distinct subdomain says "distinct product." And it concentrates the descriptive and navigational content on the hub, where it can be maintained in one place, rather than scattering it across the product sites. The domain layout is the skeleton that the rest of the map hangs on.

Within the hub, paths follow a predictable logic so that a URL is guessable and stable. Each kind of content has a clear home: documentation under a docs path with a segment per product, the blog under its own path with a segment per post, the standalone pages at clear top-level paths. The naming aims to be the obvious thing — the path for a product's documentation is that product under docs, the path for a post is that post under the blog — so that someone who knows the pattern can predict where something lives and someone who sees a URL can infer what it is. Predictable naming is a quiet usability feature: it makes the ecosystem feel coherent and lets both users and search engines build an accurate mental model of the structure.

Predictability also has a maintenance payoff. When paths follow a consistent logic, adding new content means slotting it into the existing pattern rather than inventing a new scheme each time, which keeps the URL space coherent as it grows instead of fragmenting. And when something must change, the discipline is to preserve the old URL with a redirect rather than letting it break, because external references and bookmarks point at specific URLs and the cost of a broken link is borne by the user who followed it. Stable, predictable URLs are part of what makes the ecosystem trustworthy to link to — a property whose URLs keep working is one people keep referencing.

It is easy to treat URLs as an afterthought — addresses that get assigned however is convenient as content is added — but for a multi-product ecosystem the URL structure is worth deliberate design, because it is simultaneously a navigation system, a relationship map, and a durable public interface. A URL tells a user where they are and implies where related things might be; it tells a search engine how content is organized and related; and it is a commitment, because once a URL is published and linked to, changing it breaks every reference. Treating the URL space as something to architect rather than accrete is what keeps a growing ecosystem navigable instead of letting it sprawl into an incoherent collection of arbitrary addresses.

The cost of not designing the URL structure shows up gradually and then permanently. Without a deliberate scheme, each piece of content gets whatever path seemed reasonable when it was added, the patterns diverge, and over time the ecosystem becomes a place where URLs are unpredictable, relationships are unclear, and the structure communicates nothing. And because URLs are hard to change once linked, this incoherence calcifies — you cannot easily fix it later without breaking references. Designing the structure up front, by contrast, means new content slots into an existing logic, the patterns stay consistent as the ecosystem grows, and the URL space remains a coherent, legible map. The URL structure is one of those decisions that is cheap to make well at the start and expensive to fix later, which is exactly why it deserves deliberate design rather than incidental accretion.

Beyond human navigation, a coherent URL and linking structure does specific work for search engines, which matters for an ecosystem that wants its content found. Search engines build an understanding of a site from its structure: the URL hierarchy suggests how content is organized, and the internal links suggest which pages relate to which and which are most important. A predictable path structure where a product's documentation lives at an obvious, consistent location helps a search engine map the ecosystem accurately, and dense, meaningful internal linking helps it understand the content as coherent topic areas rather than isolated pages. The structure is, in effect, a way of explaining the ecosystem to a search engine in a language it reads.

This is why the internal linking is chosen to reflect genuine relationships rather than being a mechanical web. Links that connect actually-related content — a post to the documentation it concerns, a doc to the deeper writeups about it — communicate real topical relationships that a search engine can weigh as meaningful, whereas indiscriminate linking communicates noise. The same property that makes the links useful to a human following them makes them legible to a search engine evaluating them: they encode real relevance. For an ecosystem competing to be discovered, a structure that clearly communicates its organization and the relationships within it is a genuine advantage, and it comes from the same deliberate design that makes the ecosystem navigable for people. Serving users and serving search engines, in this case, are the same work.

A property of the URL map that is easy to undervalue is stability — that URLs, once published, keep working — because it is what makes the ecosystem trustworthy to link to and build on. External references, bookmarks, and shared links all point at specific URLs, and every one of them is a small bet that the URL will keep resolving. When URLs are stable, those bets pay off and the ecosystem accumulates a growing web of inbound references that keep working; when URLs break, every broken link is a small betrayal of someone who referenced the content in good faith, and the ecosystem becomes risky to link to. The discipline of preserving old URLs with redirects when something must move is how that stability is maintained, because the cost of a broken link is borne by the user who followed it.

This stability compounds into trustworthiness over time. A property whose URLs reliably keep working is one that people and other sites become comfortable referencing, which builds the inbound links and the reputation that make an ecosystem more discoverable and more authoritative. A property whose URLs break is one that people learn to reference cautiously or not at all, which forfeits that accumulation. So URL stability is not just a courtesy to the occasional user who followed an old link; it is part of how the ecosystem earns the trust that makes it worth linking to, which feeds back into its reach. Keeping URLs stable is a long-term investment in being a place worth pointing at, which is exactly the kind of compounding, low-cost discipline that suits an operation building for the long run.

A predictable URL scheme is a usability feature precisely because it lets users and maintainers reason about the ecosystem without having to memorize it. When paths follow a consistent logic — a product's docs at that product under the docs path, a post at that post under the blog — someone who learns the pattern once can predict where anything lives, and someone who sees a URL can infer what it is. This predictability removes a small but real cognitive load: the ecosystem becomes navigable by reasoning rather than by lookup, which makes it feel coherent and trustworthy in a way an arbitrary, unpredictable URL space does not. Guessable URLs are a quiet signal that the place is well-organized.

The maintenance benefit mirrors the usability one. When the URL logic is consistent, adding new content is a matter of slotting it into the existing pattern rather than inventing a fresh scheme each time, which keeps the URL space coherent as it grows instead of fragmenting into one-off decisions. The operator does not have to deliberate about where each new thing goes, because the pattern already determines it, and the result stays consistent without ongoing effort. Predictability thus reduces cognitive load on both sides — users reason about the structure instead of memorizing it, and the maintainer follows the pattern instead of re-deciding — which is exactly the kind of low-effort coherence that suits a one-person operation maintaining a growing ecosystem. A predictable scheme designs the decisions out, which is why it is worth establishing deliberately.

Keeping URLs stable in practice requires a specific discipline: when something must move or be renamed, preserve the old URL with a redirect rather than letting it break. This matters because URLs are a public interface that others have built on — external references, bookmarks, shared links all point at specific addresses, and changing an address without a redirect breaks every one of those silently, with the cost borne by whoever followed the now-dead link. The redirect discipline treats a published URL as a commitment that outlives the convenience of changing it, which is what makes the ecosystem safe to reference. A property that honors its old URLs is one that people can link to without fear.

This discipline is a small ongoing cost that buys a large long-term benefit. Maintaining redirects as the ecosystem evolves is some effort, but the alternative — broken links accumulating as content moves and gets renamed — slowly erodes the trust and the inbound reference web that make an ecosystem discoverable and authoritative. The deprecated products that were retired, for instance, kept their old URLs working through redirects rather than simply vanishing, so that anyone who had linked to them was not left at a dead end. The redirect discipline is the operational practice that turns the principle of URL stability into reality, and it is exactly the kind of unglamorous, compounding maintenance that distinguishes an ecosystem built to last from one that decays at its edges as it changes. Honoring old URLs is honoring the people who trusted them enough to link.

The point at which a collection of properties becomes a genuine ecosystem rather than a set of separate sites is when the structure — domains, naming, and linking together — makes them function as one connected whole. Any single property can exist in isolation; what turns several into an ecosystem is that they reference each other coherently, share a legible structure, and provide paths between related things, so that a visitor landing anywhere finds the rest reachable and a search engine reads them as one organized body rather than scattered pages. The URL map is what accomplishes this transformation: it is the difference between owning several websites and operating one ecosystem.

This ecosystem effect is more than the sum of its parts, because the coherence itself creates value. A user who arrives at one tool and discovers, through clear structure and linking, that it is part of a family of related tools, with documentation and context all connected, experiences something more substantial and trustworthy than a single isolated tool. The properties reinforce each other: the hub gives the products context and discoverability, the products give the hub purpose, and the linking lets each surface lead to the others. The URL map is the connective architecture that produces this whole, which is why it is worth designing deliberately rather than letting addresses accrete. The goal was never just to give everything an address; it was to make the addresses add up to a coherent place that is more valuable, more navigable, and more trustworthy than its individual pieces would be alone.

The domain layout and naming give the ecosystem a skeleton; internal linking is the connective tissue that turns it into a navigable whole. The strategy is deliberate rather than incidental: the hub links out to each product and its documentation, the products and docs link back to the hub, and within the content, related pieces link to each other to form topic clusters. A blog post links to the relevant documentation and to its sibling posts; a documentation page links to the product it documents and to the deeper write-ups about it. These links are chosen to reflect genuine relationships — this post is relevant to that one, this doc explains that product — rather than being a mechanical web, which is what makes them useful to a reader following them and meaningful to a search engine weighing them.

Dense, real internal linking does two jobs at once. For users, it means that landing anywhere in the ecosystem provides a path to the related things they are likely to want next, so the properties function as one connected resource rather than dead-ending. For search engines, the link structure communicates which pages relate to which, helping them understand the ecosystem as a set of coherent topic areas rather than isolated pages — a meaningful relevance signal that a scattered, unlinked set of pages would not send. The internal-linking strategy is where the hub-and-spoke structure stops being just a layout and becomes an actually-connected ecosystem, which is the whole goal of the URL map: not just to give everything an address, but to make the addresses add up to a coherent place. The companion posts cover the codebase architecture behind this structure and the documentation-specific side of keeping multi-product URLs coherent.