I Canceled Notion. I Also Think You Shouldn't Cancel Your SaaS Subscriptions.

Can you vibe-code yourself out of a production outage at 2am?

I keep seeing posts about canceling SaaS subscriptions and building your own tools instead. It's not new. This conversation predates AI by years. But it's active again, and I get the appeal. Building software has genuinely never been easier.

Building is the easy part.

Someone in your team, a developer, or maybe the person who also manages your routers, puts something together. It covers the core use case. The UI works. The API does what you need. For a while, things are good.

Then something breaks. They fix it. Monthly, maybe more. You probably don't notice. Until they're on summer vacation, and their laptop comes with them. Just in case.

This is the part that doesn't show up in the "I canceled my SaaS subscriptions" post. Keeping data available. Running backups in multiple locations. Migrating data when you figure out a better way to visualize it. Handling the project manager who needs the resourcing view right now and the integration hammering the API on rapid fire, at the same time. That's not a feature. That's what the subscription actually pays for.

At EG Silverbucket, we've had thousands of conversations about resource management. That accumulates in ways that are hard to describe in a feature list. It shows up in what we choose not to build, and why.

And Then I Canceled Notion

So I canceled Notion.

I replaced it with Obsidian and GitHub, wired into my AI workflows, running on my local file system. It works great. I wouldn't go back.

The setup: Obsidian as the editor. Markdown files, local file system, syncing every ten minutes via the Obsidian plugin. GitHub as version control and backup. A Claude Code skill that lets me drop a raw idea into my knowledge base from anywhere on my computer: mid-coding session, a side conversation, a thought that hits between meetings.

When I open my laptop in the morning, I get a briefing: PRs I need to fix, review, or merge. Notes about meetings I have today. Anything with a deadline shows up as a checkbox with a date. If something is urgent enough to reach me, it does, by email or Telegram.

The whole thing is designed around one principle: my AI agents need to be able to read and write to this system as naturally as I do. Markdown files on a local file system are about as agent-friendly as storage gets.

What I Gave Up

Mobile is the biggest one. I can't pull up my notes on my phone.

Honestly? I rarely did in Notion either. Dropping a quick note on a walk is enough. I have Claude on mobile for that. Fetching and synthesizing from my knowledge base on the go would be nice someday. It's not something I've missed enough to solve yet.

GitHub permissions are all-or-nothing at the repo level. If I wanted to give someone else access to part of my system, I'd be giving them access to all of it. I haven't needed to solve that problem. That last sentence matters more than it sounds.

Two Users

My setup has exactly two users.

Me. And my agents.

When something breaks, I fix it. When I'm on vacation, the system can be down. That's fine, because I'm on vacation. When I want to change how things are organized, I change them. No one is waiting.

I'm also the person who built it. I understand every part of it. There are no surprises at 2am, because if something breaks at 2am, it's my problem and I already know the codebase.

This setup is not for everyone. It almost certainly won't replace your Notion usage, because your Notion usage almost certainly involves other people.

The Moment the Rules Change

Imagine a second person joins.

GitHub permissions become a real problem immediately. They get access to everything, or nothing. The morning briefing needs to understand their context. The capture skill needs to know the difference between their notes and mine. The sync needs to handle conflicts.

That's before we get to what happens when something breaks and they're blocked on it.

Now imagine it's not a personal knowledge base but a resourcing tool. Project managers checking capacity on a Monday morning. HR running reports. Integrations hitting the API. None of those people care whether the person who built it is available. They need the system to be up because their job depends on it.

That's the subscription you're paying for. Not the features. The operational commitment: backups in multiple locations, data migrations when you change your mind, availability when you're not around.

You can build those things yourself. But then that's your product now. The tool became the project.

The Question That Actually Matters

I don't think the right frame is "build vs. buy."

It's: who are your users, and what happens when you're unavailable?

If the answer is "just me, and nothing happens." Build it. The economics are genuinely good right now. The tools exist. Setup time is measured in hours, not months. For personal productivity, note-taking, personal automation: the case for building has never been stronger.

If the answer is "other people, and they're blocked." Buy it. Or if you build it, understand that you've signed up for something closer to running a product than writing a script.

The vibe-coding era is genuinely changing what's possible to build quickly. It's not changing what it means to run something reliably for people who depend on it.

If someone tells me their self-built tool works great: let's continue this conversation in six months.

---

The automation rabbit hole goes deep. If you're curious about where the line is between useful automation and a system that starts running you, I wrote about my own pivot from n8n to Python, and what that taught me about knowing when your tools start fighting you.