Skip to main content
GASSTUDI
Building in Public5 min read

The Cross-Venture Content Hub We Almost Over-Engineered

Designing a way for separate ventures to share a content backend without merging their identities: how 'siloed channels, shared backend' beat one unified dashboard.

Nic DeMore

Nic DeMore

Founder, GAS Studio · August 20, 2026

Overhead view of a minimal workspace with a laptop and notebook

Every venture under GAS Studio needs somewhere to publish content, this Journal, FOA's writing, Giveable's brand and impact stories, and eventually whatever comes next. The obvious question was whether to build that once, as shared infrastructure, or build it separately for each venture and accept the duplicated setup work. I chose to build it once. Where I almost went wrong was in how much "once" should actually mean.

The version I almost built

My first pass at the design merged more than the backend. I was sketching a single dashboard where all the ventures' content lived side by side, one editorial calendar, one set of categories, one place to see everything being published anywhere in the portfolio at a glance. On paper it looked efficient. Fewer places to check, one system to maintain, a bird's-eye view of everything at once.

The problem showed up as soon as I thought about it from the reader's side instead of my own. Giveable and FOA are not the same brand, do not serve the same audience, and shouldn't feel like extensions of the same identity when someone lands on either one. A merged view that made sense for me as the person running everything would have actively worked against the ventures themselves, blurring lines that need to stay distinct for the ventures to build their own credibility.

The distinction that actually mattered

The thing worth sharing was never the identity, it was the plumbing. Content storage, publishing workflow, the technical machinery that takes a draft and turns it into a live page, that's genuinely the same problem across every venture and there's no good reason to solve it four separate times. What needed to stay separate was everything downstream of that, the channel, the categories, the voice, the audience each piece is actually written for.

Once I separated those two layers explicitly, the design got a lot simpler. Shared backend, siloed channels. One system doing the technical work underneath, with each venture's content living in its own clearly separated space on top of it, no shared calendar, no merged categories, no single view that implies these are all the same thing.

Why the simpler shape actually won

The unified dashboard version would have been more impressive to build and more satisfying to look at as a single artifact. It also would have optimized for my convenience at the direct expense of each venture's distinctiveness, which is exactly backwards from what these ventures need to succeed on their own terms. Giveable needs to read like Giveable. FOA needs to read like FOA. A shared dashboard that treated their content as interchangeable rows in the same table would have quietly undermined that every time I looked at it and started thinking about it that way.

The siloed-channels version is less elegant as a single piece of engineering. It's more correct for what these ventures actually need, which is real separation with shared machinery underneath, not shared identity with cosmetic separation on top.

The general lesson I keep relearning

Shared infrastructure is almost always worth building once. Shared identity is a different decision entirely, and it's easy to accidentally bundle the two together because they often get built by the same person, at the same time, for the same convenience. The question that saved me here was asking, for every piece of the design, whether it was solving a technical problem or an identity problem, and refusing to let a technical shortcut quietly become an identity decision I hadn't actually made on purpose.

What this means as more ventures get added

The current shape holds up reasonably well as the portfolio grows, because adding a new venture means adding a new siloed channel on top of infrastructure that already exists, not redesigning the shared layer itself. That's the actual test of whether the separation was drawn in the right place. If adding a fifth venture required rethinking the backend, I'd have merged the wrong layer. Because it just means standing up a new channel, I'm fairly confident the line ended up where it needed to be.

Related Venture

Good At Scale Studio

Doing good, at scale.

Visit

Share this entry