Why I’m Building TheVan.dev as a Personal Operating System
TheVan.dev was never meant to be just a portfolio website, a Twitch channel, or a link hub. Those things matter, but they are not enough. The real idea is to build a personal operating system: a place where content, projects, community, services, sponsorships and learning reinforce each other.
The goal is not to look bigger than I am. The goal is to make the work visible: what I build, how I think, and which decisions I make when an idea moves from notes to code, from a live session to a reusable asset.
The problem I’m solving
Without a system, every live stream dies when OBS closes. Every idea stays in a note. Every clip depends on daily energy. Every potential sponsor stays vague. Every service offer becomes weaker because there is no public proof behind it.
The personal operating system exists to reduce that waste.
A single live session can become:
- a technical note;
- a backlog card;
- a vertical clip;
- a Lab article;
- a case study;
- a future sponsor pitch;
- a community resource.
Not everything needs to become everything. But the system should make reuse possible without turning me into my own project manager.
Why “operating system” and not “content calendar”
A content calendar tells you what to publish. An operating system defines how information moves.
For TheVan.dev I need a structure that connects:
- Notion as the operational cockpit;
- Twitch as the build and relationship layer;
- YouTube, Shorts, Reels and TikTok as distribution;
- Discord and Telegram as community layers;
- the website as the home base;
- sponsors and services as coherent monetization.
The calendar is just one view. The system is the flow.
The rule: proof-of-work before posture
I don’t want to build a brand that talks about AI, automation and creator workflows without showing anything real. I want the content to prove the work.
That means publishing real, imperfect pieces:
- experiments that only half-worked;
- ugly but useful workflows;
- debatable technical decisions;
- tools that overpromise;
- automations that work but need simplification.
Credibility does not come from sounding polished. It comes from letting people see the workshop.
What goes into the system
Right now I’m building the base layers:
- a sponsor page that does not sound corporate;
- a sponsor CRM in Notion;
- a headless CMS for the Lab;
- a live → clip → article content pipeline;
- a Telegram/Discord community structure;
- a reusable library of cases and assets.
Every piece needs a function. If a document does not help me publish, sell, decide or learn, it is probably decoration.
What I want to avoid
There are three traps I want to avoid.
The first is fake agency theatre: using “we”, writing like a soulless B2B landing page, pretending to be a bigger structure when the actual value is personal.
The second is over-automation: building huge pipelines before having enough content to process. Automation should remove friction, not become another infinite project.
The third is content grinding: publishing just to fill channels without accumulating assets or trust.
The result I want
In a few months, someone should be able to land on TheVan.dev and understand three things quickly:
- what I can build;
- how I think while building;
- why it might make sense to work with, sponsor or follow the project.
If an article, live stream or clip does not support at least one of those outcomes, it needs to be reconsidered.
Next step
The next step is to use this Lab as the public memory of the workshop. Not just announcements, but cases. Not just opinions, but decisions. Not just tools, but real workflows.
TheVan.dev is the home. The Lab is the workbench.