Forem: Kanishk Kumar Mishra

Stop Trusting Memory: Engineering Reliable Notion Backups That Just Work

Kanishk Kumar Mishra — Fri, 03 Apr 2026 09:31:04 +0000

From manual exports to a cross-platform, OS-native backup system

Backing up your Notion workspace shouldn’t depend on memory.

But in practice, it does.

If you rely on Notion for serious work—notes, projects, documentation—you’ve probably experienced this pattern:

“I should probably export this…”
“I’ll do it later…”
And then… you don’t

Until something breaks.

The problem isn’t that backups are hard.

The problem is that the workflow around them is unreliable.

🔗 Explore the Project

Check out the project here:

https://kanishkmishra143.github.io/NotionSafe/

⚠️ The Real Issue: Backups That Depend on Humans

Notion provides export functionality.

But the default workflow looks like this:

Manually trigger export
Wait for processing
Download and organize files
Repeat regularly (if you remember)

This creates a system that depends on:

Memory
Discipline
Timing

And that’s exactly what backups should not depend on.

This isn’t a feature gap.

It’s a reliability problem.

💡 The Shift: From Manual Action → Background System

Instead of asking:

“How do I back up my Notion workspace?”

I reframed it:

“How do I make backups happen reliably without thinking about them?”

That shift led to building NotionSafe.

🚀 What is NotionSafe?

NotionSafe is a cross-platform desktop application that automatically backs up your Notion workspace into structured, timestamped local snapshots.

It’s designed around one core idea:

Backups should happen without interrupting your workflow.

At a high level:

Configure what to back up
Set up scheduling once
Let the system handle everything

No reminders. No manual exports. No friction.

⚙️ Workflow Model

Traditional approach

Remember → Export → Download → Organize → Repeat

NotionSafe

Configure once → Scheduled backups → Local history maintained automatically

The difference is simple:

From effort-based
To system-driven

🐧 Linux vs 🪟 Windows: Designing for Native Reliability

Making this work across platforms wasn’t just a UI problem.

It was a systems design problem.

🐧 Linux: Composable and Predictable

On Linux, the system provides powerful primitives:

systemd timers for scheduling
Secure credential storage via keyring
Native GTK for lightweight interfaces

This allowed:

Background execution independent of the app
Secure token handling
Clean integration with the OS

The result: a solution that feels native and reliable by default.

🪟 Windows: Different Constraints, Different Approach

Windows required a different strategy:

Task Scheduler replaces systemd
Different credential storage mechanisms
UI expectations differ significantly

Instead of forcing the Linux approach onto Windows:

Used Task Scheduler for background execution
Built a Qt-based interface for native experience
Designed workflows to feel consistent, not identical

This was a key decision:

Cross-platform doesn’t mean same implementation.

It means same experience.

⚙️ Key Design Decisions

1. Native UI Over One-Size-Fits-All

GTK on Linux
Qt on Windows

This ensures:

Better performance
Familiar interaction patterns
OS-level consistency

2. OS-Level Scheduling Over In-App Timers

Instead of running timers inside the app:

Linux → systemd timers
Windows → Task Scheduler

This ensures:

Backups run even if the app is closed
No dependency on app uptime
True background reliability

3. Local Snapshots + Optional Git Sync

Each backup creates:

Timestamped local snapshot
Structured file output

Optional:

Git-based version history
External drive copies

This provides:

Fast recovery (local)
Long-term history (Git)

4. Config-Driven Setup (With a Wizard)

Instead of exposing everything upfront:

Guided setup
Config stored cleanly
Minimal cognitive load

This balances:

Power
Simplicity

🔍 What Actually Gets Backed Up?

Each run:

Exports selected pages/databases
Stores them as timestamped snapshots
Organizes them for easy retrieval

This creates a recoverable, versioned history of your workspace.

🧠 Design Philosophy

This project wasn’t about backups.

It was about removing anxiety from a critical workflow.

Core principles:

Reliability over visibility → it should just work
Automation over discipline → remove human dependency
Native integration over abstraction → use the OS properly
Local-first over cloud dependency → you own your data

🎯 Who Is This For?

NotionSafe is built for:

People who rely on Notion for real work
Users who want local ownership of their data
Cross-platform workflows
Anyone who values reliable systems over manual routines

📌 What This Project Really Represents

This wasn’t about backing up Notion.

It was about solving a deeper problem:

Systems that depend on humans will eventually fail.

The solution:

Design systems that remove human dependency wherever possible.

🚀 Final Thought

You don’t notice backups when they work.

You only notice them when they fail.

The goal isn’t to think about backups more.

It’s to stop thinking about them entirely.

Stop Breaking Flow: Engineering Instant Audio Switching Across Linux and Windows

Kanishk Kumar Mishra — Fri, 03 Apr 2026 08:52:58 +0000

🎧 From a simple pactl script to a cross-platform, low-latency system tool

Switching audio devices should be instant.

In practice, it isn’t.

If you regularly use multiple audio outputs—headphones, speakers, Bluetooth devices—you’ve likely run into the same friction:

Opening system settings just to switch output
Clicking through nested menus
Losing focus from your current task
Repeating this multiple times a day

This isn’t a hard problem.

But it’s a bad workflow problem.

🔗 Explore the Project

Check out the project here:
https://kanishkmishra143.github.io/Sink-Switch/

⚠️ The Real Issue: Friction, Not Functionality

Modern operating systems already support multiple audio devices.

The issue isn’t capability—it’s interaction.

Switching is UI-heavy instead of keyboard-first
No fast, predictable way to move between preferred devices
Context switching breaks flow

You’re not lacking features.

You’re lacking speed and intent in the workflow.

💡 The Shift: From Selection → Cycling

Instead of asking:

“How do I switch audio devices faster?”

I reframed it as:

“How do I eliminate the need to choose every time?”

That led to a simple idea:

Cycle through a predefined set of devices using a single action.

No menus. No decisions. Just movement.

🚀 Introducing Sink Switch

Sink Switch is a cross-platform utility for instantly switching audio outputs using a hotkey, CLI command, or lightweight GUI.

👉 :contentReference[oaicite:0]{index=0}

At its core, the workflow is simple:

Select the devices you care about
Define a cycle order
Trigger a hotkey or command
Switch instantly

No UI friction. No repeated decisions.

⚙️ Core Design Decisions

1. Cycling > Selection

Traditional approach:

Open settings
Select device
Confirm

Sink Switch approach:

Press hotkey → next device

This makes switching:

Faster
Predictable
Muscle-memory driven

2. Config-Driven State

Instead of dynamically choosing devices every time:

You define a cycle list once
The system remembers it
Switching becomes deterministic

This removes:

Cognitive overhead
Repeated configuration

3. Keyboard-First Workflow

Everything is designed around:

Hotkeys
CLI commands
Minimal UI interaction

Because speed comes from not leaving your current context.

🐧 Linux vs 🪟 Windows: A Systems Perspective

One of the most interesting parts of building Sink Switch was how different the platforms are.

On Linux

Clean interfaces via PulseAudio / PipeWire
pactl provides direct control
Bash was enough for a fast, native-feeling solution

Result:

A lightweight, scriptable system that integrates naturally into the environment.

On Windows

Outdated and restrictive audio APIs
PowerShell + AutoHotkey approach broke down quickly
No reliable abstraction for consistent device control

This forced a shift:

Rebuild the Windows version in Go using Core Audio APIs directly.

🛠️ Why Go for Windows?

The Go implementation enabled:

Direct interaction with Windows Core Audio APIs
Reliable, low-latency switching
Better control over device enumeration and state
A native dashboard + CLI interface

This wasn’t just a rewrite.

It was a necessary architectural upgrade.

🔍 A Subtle Edge Case

One interesting challenge:

Tools like FxSound always appear as the active output device—even when they’re just acting as a processing layer.

That means:

The system reports a “virtual” device
But the actual output is happening elsewhere

Fixing this required:

Tracking real device state beyond surface-level API data
Designing around how audio is routed, not just reported

This is where a simple tool becomes a systems problem.

🧠 Design Philosophy

This project wasn’t about building another utility.

It was about removing friction from a high-frequency workflow.

Key Principles

1. Speed Over Flexibility

Fewer decisions → faster execution.

2. Predictability Over Complexity

Cycling ensures consistent behavior every time.

3. State Over Stateless Actions

The system remembers your preferences.

You don’t have to reconfigure each time.

4. Flow Over Features

The goal isn’t more functionality.

The goal is not breaking your focus.

📂 What It Enables

Sink Switch becomes especially useful for:

Multi-device setups (headphones + speakers + Bluetooth)
Developers working in full-screen environments
Linux users on tiling WMs like Hyprland
Anyone optimizing for keyboard-first workflows

📌 What This Project Really Represents

This wasn’t about switching audio devices.

It was about identifying a small but frequent annoyance—and solving it properly.

The pattern is simple:

Identify friction → remove decisions → optimize for flow

That pattern applies everywhere:

Dev tools
System utilities
Even product design

🚀 Final Thought

Good tools add features.

Great tools remove steps.

And the best ones become invisible—because they just fit into your workflow.

Sink Switch is one of those tools.

Stop Babysitting Symlinks: Designing a Safer, Faster TUI Workflow

Kanishk Kumar Mishra — Fri, 03 Apr 2026 08:29:39 +0000

📝 From `ln -s` to Intentional Workflows: Building an Interactive Symlink Creator in Go

Managing symlinks should be trivial. In practice, it's anything but.

If you've worked with symlinks long enough—especially while managing dotfiles, configs, or multi-environment setups—you've likely fallen into the same repetitive loop:

Double-check source and destination paths
Worry about overwriting something important
Manually resolve conflicts
Repeat the process, carefully, every single time

The problem isn't that symlinks are complex.

The problem is that the workflow around them is fragile.

🔗 Explore the Project

You can check out the full project here:
https://github.com/KanishkMishra143/Interactive-Symlink-Creator

⚠️ The Real Issue: Workflow, Not Command

The ln -s command itself is simple. But the moment you scale beyond a single link, things start breaking down:

No structured navigation → long, error-prone paths
No safety layer → easy to overwrite unintentionally
No batch operations → repetitive, manual work
No feedback loop → you don't know what went wrong until it's too late

This isn't a tooling problem.

It's a workflow design problem.

💡 The Shift: From Commands → Experience

Instead of asking:

"How do I create symlinks faster?"

I reframed the problem:

"How do I make symlink creation intentional, safe, and repeatable?"

That shift led to building Interactive Symlink Creator (ISC).

🚀 What is ISC?

ISC is a full-screen terminal application that guides you through the entire symlink creation process—from selecting directories to resolving conflicts—without dropping back into raw shell commands.

It's built using Go and a TUI framework to create a structured, keyboard-first experience.

Workflow Overview

Choose a source directory
Choose a destination directory
Select files/folders to link (bulk supported)
Handle conflicts interactively
Review results and restart if needed

Everything happens inside a single, continuous interface.

⚙️ Key Capabilities

1. Interactive Directory Navigation

Instead of typing long paths manually, ISC provides a two-column navigator for selecting source and destination directories.

This reduces both cognitive load and error probability.

2. Bulk Selection Before Execution

You don't execute commands one by one.

You:

Select multiple files/folders
Review your selection
Execute in a single pass

This shifts the workflow from reactive → planned.

3. Conflict Resolution That Doesn't Break Flow

When conflicts occur, you're not thrown back into the shell.

You get structured options:

Overwrite
Skip
Rename

All handled inline, without losing context.

4. Dry-Run Mode (Critical for Safety)

Before making any changes, you can simulate the entire operation:

go run . --dry-run create

This lets you validate decisions without touching the filesystem.

A small feature—but high leverage in preventing mistakes.

5. Cleanup for Broken Symlinks

Symlink-heavy environments tend to accumulate broken links over time.

ISC includes a cleanup command:

go run . cleanup /path/to/search

This scans and removes broken symlinks recursively.

🧠 Design Philosophy

This project wasn't about building another CLI tool.
It was about eliminating friction from a recurring workflow.

Key Principles

1. Full-Screen TUI Over Prompt-Based CLI

Prompts interrupt flow. A TUI maintains continuity.

2. Restartable Workflows

No abrupt exits. You can restart the entire process seamlessly after completion.

3. Keyboard-First Interaction

Every action is optimized for speed without leaving the keyboard.

4. Structured State Over Stateless Commands

Traditional CLI usage is stateless—you issue commands and hope for correctness.

ISC maintains state across steps:

What you selected
What conflicts exist
What actions you chose

This drastically reduces mental overhead.

🛠️ Why Go + TUI?

The initial version was a Bash script.

It worked—but hit limits quickly:

Hard to scale cleanly
Poor UX for multi-step workflows
Difficult to maintain or extend

Rewriting in Go enabled:

Better structure (modular architecture)
Clear separation of concerns
Predictable behavior across environments

The TUI layer allowed transforming a command into an experience.

📂 Under the Hood

The project follows a layered structure:

internal/
├── domain/
├── fs/
├── services/
└── ui/
    ├── components/
    ├── manager/
    └── styles/

This separation ensures:

Filesystem logic is isolated
UI remains independent
Business logic is reusable

It's not just a tool—it's designed to be extendable.

🎯 Who Is This For?

ISC is built for:

Developers managing dotfiles
Linux users working heavily in terminals
Anyone tired of manually handling symlinks
People who care about safe, repeatable workflows

📌 What This Project Really Represents

This wasn't about symlinks.

It was about taking a small, annoying, everyday task—and treating it like a real engineering problem.

The outcome isn't just a tool.
It's a pattern:

Identify friction → redesign the workflow → build around safety and intent

That pattern scales far beyond this project.

🚀 Final Thought

The best projects aren't always flashy.

Sometimes, they're the ones that:

Remove friction
Reduce mistakes
And quietly make your daily workflow 10x smoother

And those are often the ones worth building.

Forem: Kanishk Kumar Mishra

Stop Trusting Memory: Engineering Reliable Notion Backups That Just Work

From manual exports to a cross-platform, OS-native backup system

🔗 Explore the Project

⚠️ The Real Issue: Backups That Depend on Humans

💡 The Shift: From Manual Action → Background System

🚀 What is NotionSafe?

⚙️ Workflow Model

Traditional approach

NotionSafe

🐧 Linux vs 🪟 Windows: Designing for Native Reliability

🐧 Linux: Composable and Predictable

🪟 Windows: Different Constraints, Different Approach

⚙️ Key Design Decisions

1. Native UI Over One-Size-Fits-All

2. OS-Level Scheduling Over In-App Timers

3. Local Snapshots + Optional Git Sync

4. Config-Driven Setup (With a Wizard)

🔍 What Actually Gets Backed Up?

🧠 Design Philosophy

Core principles:

🎯 Who Is This For?

📌 What This Project Really Represents

🚀 Final Thought

Stop Breaking Flow: Engineering Instant Audio Switching Across Linux and Windows

🎧 From a simple pactl script to a cross-platform, low-latency system tool

🔗 Explore the Project

⚠️ The Real Issue: Friction, Not Functionality

💡 The Shift: From Selection → Cycling

🚀 Introducing Sink Switch

⚙️ Core Design Decisions

1. Cycling > Selection

2. Config-Driven State

3. Keyboard-First Workflow

🐧 Linux vs 🪟 Windows: A Systems Perspective

On Linux

On Windows

🛠️ Why Go for Windows?

🔍 A Subtle Edge Case

🧠 Design Philosophy

Key Principles

1. Speed Over Flexibility

2. Predictability Over Complexity

3. State Over Stateless Actions

4. Flow Over Features

📂 What It Enables

📌 What This Project Really Represents

🚀 Final Thought

Stop Babysitting Symlinks: Designing a Safer, Faster TUI Workflow

📝 From ln -s to Intentional Workflows: Building an Interactive Symlink Creator in Go

🔗 Explore the Project

⚠️ The Real Issue: Workflow, Not Command

💡 The Shift: From Commands → Experience

🚀 What is ISC?

Workflow Overview

⚙️ Key Capabilities

1. Interactive Directory Navigation

2. Bulk Selection Before Execution

3. Conflict Resolution That Doesn't Break Flow

4. Dry-Run Mode (Critical for Safety)

5. Cleanup for Broken Symlinks

🧠 Design Philosophy

Key Principles

1. Full-Screen TUI Over Prompt-Based CLI

2. Restartable Workflows

3. Keyboard-First Interaction

4. Structured State Over Stateless Commands

🛠️ Why Go + TUI?

📂 Under the Hood

🎯 Who Is This For?

📌 What This Project Really Represents

🚀 Final Thought

📝 From `ln -s` to Intentional Workflows: Building an Interactive Symlink Creator in Go