Building a Hub of Single-Purpose Sites Instead of One Big App: What Worked, What Broke
Most product advice points in one direction: put everything in one app, one login, one feed, and grow from there. The OneLifeVibe hub went the other way — a collection of separate, single-purpose websites behind one front door, at OneLifeVibe. Each site does one everyday job: a shared household list, a neighbourly help board, an interactive bedtime story, a net-worth check, a daily horoscope. A visitor opens the right tool, finishes the job, and leaves. This post is about what that architecture made easier, what it made harder, and what would change in a rebuild.
What worked
A narrow job is a design constraint that does the deciding. When a site only has to finish one task, most feature arguments settle themselves. Anything that does not help a visitor complete that one job in a single sitting is out, however interesting it is. There is no feed to fill and no engagement loop to feed, so the homepage can be the tool itself.
Returning is one step, not a search. Single-purpose sites have always had a findability problem: a useful tool visited once is effectively lost if its name is forgotten. A single front door fixes that without merging the products. Bookmarks scatter; a hub address is easy to remember, and from there every tool is one click away. The fiftieth visit works exactly like the first.
Lessons transfer even when code stays separate. Support questions, onboarding friction, and naming confusion rhyme across sites. Fixing a confusing label on one site usually reveals the same confusion on three others. Running several narrow products in parallel turned into a fast feedback loop for patterns that a single product would have taken much longer to surface.
What broke
Discovery is split, not pooled. One big app concentrates search presence and word of mouth in one place. Separate sites each start from zero, and a visitor who loves one tool may never learn the others exist. The hub page helps, but only for people who arrive through it — most arrive through a search result, deep inside one site, and leave the same way.
Consistency is a manual discipline. Shared sign-in conventions, similar navigation, and a common visual language do not happen automatically across separate sites. Without deliberate effort they drift, and drift is expensive: a returning visitor should feel at home on any site in the collection without relearning anything. Checklists beat memory here — every launch and every redesign gets checked against the same short list.
Maintenance multiplies quietly. Each site is simple, but there are several of them. Updates, monitoring, backups, and small fixes repeat per site. Automating the boring parts early was not optional; it was the difference between a fleet that stays healthy and one that slowly rots at the edges.
The trade-off, honestly
The hub model gives up pooled discovery and operational simplicity. What it buys is clarity: every site can be judged on whether it finishes its one job well, and a weak site can be improved or retired without touching the others. For tools people use occasionally and purposefully — rather than daily and socially — that trade has held up.
For other builders: do you keep separate focused products separate, or fold them into one platform once they share an audience? The discovery argument for folding is strong, and the clarity argument against it is strong too — curious how others have called it.