Every builder eventually faces the same fork in the road: keep adding features to the one app that is working, or split the next idea into its own small product. OneLifeVibe took the second path, and the hub is the record of what that choice costs and what it buys.
The setup
Each site in the hub does one job. One holds a family calendar and shared lists. One tracks what a household owns and owes. One arranges help between neighbours. One lets readers vote on what happens next in a story. None of them tries to do any of the others' work, and that restraint is deliberate rather than accidental.
What worked
A focused tool stays trustworthy. A household board cluttered with entertainment stops feeling like a reliable board. A money tracker surrounded by social features stops feeling private and serious. When a visitor arrives, finishes the one job, and leaves without learning a new system, the tool earns a place in a routine. Most repeat use comes from that feeling, not from feature count.
Restraint is a feature, even when it is invisible. Saying no to feeds, messages, and shopping inside every service keeps each one fast to understand. The cost of a new feature is rarely the build time. It is the confusion it adds for everyone who came for the original job.
A hub solves the findability problem that splitting creates. Separate focused sites are easy to forget, especially the ones used a few times a year. Gathering them behind one address means the route back does not depend on a search, a saved message, or a bookmark folder organised in a hurry. The visitor remembers one place, then picks the tool that matches the job in front of them. That is the whole idea behind OneLifeVibe: focused websites grouped behind a single front door, each keeping its own purpose, audience, and pace.
What broke
Maintenance multiplies. Every additional site is another deploy, another set of pages to check, another small thing that can quietly break. The hub model only works if operations stay boring and standardised across sites, because there is no spare attention for twelve special cases.
Cross-links tempt scope creep. Once sites sit side by side, it is tempting to merge accounts, merge feeds, and merge purposes "for convenience". Each merge chips away at the clarity that made the separate sites worth visiting. The hub has to stay a doorway, not become a blender.
Discovery is slower at first. A single big app gets one launch story. A hub of focused tools has to earn attention one job at a time, and early on that feels like pushing several small stones instead of one large one.
Lessons worth keeping
- If a new idea needs its own audience and its own pace, it probably needs its own site.
- Judge a feature by what it does to trust in the core job, not by what it adds to a feature list.
- Build the front door early. Focused tools without a shared way back are just scattered bookmarks.
Splitting is not free, and neither is merging. The honest summary is that one job per site keeps each tool clear enough to be trusted, and a hub keeps the collection findable enough to be used. The trade is operational discipline, paid every week, for clarity that visitors can feel on the first visit.
Discussion welcome: for anyone running more than one small product, where is the line between a helpful hub and a distraction?
