V
ITEN
← Back to LabCase Study

How I Turned Notion into a Cockpit for Content, Sponsors and Community

An operational case study on how Notion becomes the HQ for backlog, sponsors, community, media kit, pitches and the TheVan.dev editorial pipeline.

8 minProof level · Prototype
#notion#content-engine#sponsor#community#leonardvs-osNotion

How I Turned Notion into a Cockpit for Content, Sponsors and Community

This piece is part of the Leonardvs OS workshop: the personal creative and operational system I am building to connect tools, automation, content, community and real work inside TheVan.dev.

For a long time I used Notion like many people do: notes, lists, ideas and a few useful databases. But a storage space is not enough. If I want TheVan.dev to become a serious public project, Notion needs to become a cockpit: a control panel where ideas enter, change state and become output.

This case study describes the current version of the system. It is not final. It is a living prototype.

The problem

TheVan.dev has too many surfaces to manage from memory:

  • live content;
  • vertical clips;
  • Lab articles;
  • sponsors;
  • services;
  • Telegram/Discord community;
  • metrics;
  • website backlog;
  • future automations.

If every area lives in a separate file, the system breaks. If everything lives in one giant page, it becomes an elegant dumpster.

I needed a structure that could do three things:

  1. track decisions;
  2. turn content into assets;
  3. make the next step visible.

The current structure

The cockpit is organized into specialized databases:

  • a unified operational backlog;
  • Content Engine for ideas and formats;
  • Content Library / Blog CMS for publishable articles;
  • Sponsor & Partner CRM for potential collaborations;
  • Metrics Weekly for minimal tracking;
  • Community & Discord for community assets and initiatives;
  • Automations & Agents for pipelines and agents.

The rule is simple: every database must answer a different question. If two databases answer the same question, I am creating unnecessary complexity.

From raw content to asset

The ideal pipeline looks like this:

  1. an idea appears during a live stream, chat or work session;
  2. it becomes a card in the Content Engine;
  3. if it has substance, it becomes a Lab draft;
  4. if it works on video, it generates clip candidates;
  5. if it has commercial value, it becomes a case study or sponsor pitch;
  6. if it helps the community, it becomes a Discord/Telegram resource.

Not every idea must complete the whole path. But having the path prevents every piece of content from being treated as an isolated object.

Sponsors without selling smoke

The sponsor CRM is not designed for aggressive outreach. It is designed for better thinking.

For each brand or tool I want to see:

  • real fit with dev, AI, creator or community audiences;
  • reputation risk;
  • possible format;
  • relationship status;
  • next action;
  • whether organic proof-of-work already exists.

That last part matters. Before contacting big tools, I want published content already in place. Then the pitch does not sound like “please sponsor me”; it sounds like “I already built something useful around your world”.

The Lab as final output

The Content Library / Blog CMS database is the bridge between Notion and the website. Articles move from Draft to Published and the site reads them as a headless CMS.

Each article has:

  • slug;
  • status;
  • language;
  • type;
  • excerpt;
  • SEO title;
  • SEO description;
  • tags;
  • proof level;
  • reading time;
  • public URL.

This lets me write in Notion while publishing on TheVan.dev, without turning the site into another editorial admin panel.

What already works

The system forces me to think in assets. A note is not just a note: it can become an article, a clip, a sponsor card or a community resource.

The separation between ideas and publications also works. The Content Engine can stay messy. The Blog CMS should stay cleaner.

The “few fields, but useful” principle works too. Every property should help filter, publish or decide.

What I would improve

The fragile part is maintenance. A system like this can become heavy if every small idea requires ten fields.

Next iterations should simplify:

  • faster templates;
  • automations that create drafts from live notes;
  • sponsor follow-up reminders;
  • a more automated metrics dashboard;
  • links between published content and performance.

Result

Notion is not “where I write things”. It is the cockpit where TheVan.dev decides what becomes public, what becomes commercial and what remains an experiment.

That difference matters: an archive stores. A cockpit moves.