If you use Claude Code for both personal and work accounts, logging in and out gets old fast. The cleaner setup is to give each account its own config directory. Claude stores local auth and session state there, so separate directories act like separate profiles. The result is simple:

• claude can stay on your default account
• claude-work can open your work account
• no repeated sign-in/sign-out cycle

How it works

Claude Code can be launched with a custom CLAUDE_CONFIG_DIR.

Example:

CLAUDE_CONFIG_DIR="$HOME/.claude-work" claude

When you do that, Claude uses ~/.claude-work instead of the default config directory. That means auth, session history, and local state stay isolated from your main account.

Fish setup

If you use fish, add this to ~/.config/fish/config.fish:

function claude-work
    env CLAUDE_CONFIG_DIR="$HOME/.claude-work" claude $argv
end

Reload your shell:

source ~/.config/fish/config.fish

Zsh setup

If you use zsh, add this to ~/.zshrc:

alias claude-work='CLAUDE_CONFIG_DIR="$HOME/.claude-work" claude'

Reload your shell:

source ~/.zshrc

Create the separate profile directory

Run this once:

mkdir -p ~/.claude-work

Then start the isolated profile with:

claude-work

The first time it opens, log into your work account inside that profile.

What your final workflow looks like

Once setup is done:

• claude uses your default profile
• claude-work uses your work profile

That gives you clean switching between accounts without cross-contaminating local state.

Scaling to more than two accounts

This pattern works for any number of accounts or clients. Examples:

CLAUDE_CONFIG_DIR="$HOME/.claude-client-a" claude

CLAUDE_CONFIG_DIR="$HOME/.claude-client-b" claude

CLAUDE_CONFIG_DIR="$HOME/.claude-lab" claude

You can wrap each one in a shell alias or function:

• claude-work
• claude-acme
• claude-prod

One useful safety check

After launching a profile, run /status inside Claude to confirm which account and session you are using.

That is the easiest way to avoid doing work in the wrong account.

Why this setup is worth it

• no repeated login/logout flow
• separate local state per account
• cleaner personal vs work separation
• easy to remember and easy to extend

If you manage multiple Claude Code identities on one laptop, this is the simplest setup that stays practical.

Every side project needs a logo. Not a designed-by-a-professional logo — just something that says “this has a visual identity.” A favicon, a social card, something to put in the README. The usual solution is to spend 20 minutes in Figma making something barely passable, or pay for a tool that assumes you want to build a Fortune 500 brand.

I wanted neither. I wanted to pick an icon, drop it on a colored background, and export it. Done. That’s svglogo.dev.

What it does

You search for an icon from the Iconify library — thousands of icons covering every major icon set — pick a background color or gradient, adjust the border radius, set an outline if you want one, and export. SVG, PNG, or ICO. Everything runs in the browser, no server needed for the core logo generation.

The result is a clean icon-based logo mark you can drop into a landing page, a GitHub repo, or a browser tab in under a minute.

Night one

The first commit landed at 11<29> PM on March 11. I went with Next.js — familiar, fast to set up, gets out of the way.

By 2 AM I had:

• Icon search and picker (Iconify’s React component with a searchable grid)
• Background color and gradient controls
• Border radius slider
• Icon outline/border toggle
• Randomize button to generate a random logo with one click
• Copy/paste support — copy your config as JSON, paste it somewhere else
• Animated dice button because a randomize button should feel fun
• Tooltips on every control

The core loop was working. Pick icon → style it → export it.

The dock UI

My first instinct was a canvas-based design — a drag-and-drop editor where you’d position elements and manipulate them directly. I built a rough version. It felt wrong immediately. Too heavy. Too much clicking around to do simple things. The kind of UI that makes you feel like you’re using design software when you just want to change a background color.

I scrapped it and asked myself what the actual interaction was: the user looks at the preview and tweaks controls until it looks right. That’s it. So I put the preview front and center, and built a dock at the bottom of the screen — a fixed bar with every control always visible and one click away.

No panels to open. No tabs to switch. You see the logo, you reach down to the dock, you adjust. The whole thing is instant.

I added undo/redo early. It’s one of those things that feels like polish but is actually table stakes. If you accidentally blow away a gradient you liked, you need to get it back.

Keyboard shortcuts

Power users want keyboard shortcuts. I added an InfoFab — a floating button that shows the available shortcuts:

• R — randomize
• V — paste config from clipboard
• Ctrl+Z / Ctrl+Shift+Z — undo/redo

The shortcut for paste was originally P but I changed it to V since V is the mental model people already have for paste.

The sharing problem

A logo tool without sharing is just a local toy. I wanted people to be able to share a logo configuration — a URL that anyone could open and see the same logo.

The implementation is straightforward: serialize the logo config to a JSON object, store it server-side, and return a short ID. The share URL is just /?s=[id] — a query param on the homepage. When someone opens it, the config is fetched and loaded into the editor.

After migrating to Cloudflare, I swapped the storage layer to Cloudflare KV — no separate Redis instance to manage, globally distributed, and the pricing is generous enough that a logo tool never has to think about it.

Collections

After sharing, the next obvious feature was saving. People wanted to collect logo variants — try five different color combinations and keep the ones they liked.

Collections are stored in localStorage — no login, no backend, no friction. You click the heart button and the config is saved. Your collection persists across sessions in the same browser.

It’s the right call for a tool like this. A sign-in flow would add complexity and kill the “open and go” experience that makes the tool useful.

Onboarding

A tool with a clean UI can still be confusing if you don’t know where to start. I added an onboarding wizard — a short guided tour that highlights the main controls in sequence. It runs on first visit and can be triggered again from the info button.

The tour doesn’t lock you out of the UI while it runs. It just highlights the relevant area and tells you what it does. Then it gets out of the way.

The migration: Next.js → TanStack Start

After launch and the Reddit feedback wave, I migrated from Next.js to TanStack Start. The trigger was Cloudflare — TanStack Start deploys to Cloudflare Workers with almost no friction, and the performance difference is noticeable. Faster cold starts, better edge routing, and the app just feels snappier.

Once I started looking at Cloudflare seriously, the full picture clicked. TanStack Start’s routing model also fits the app better than Next.js did.

Speaking of Cloudflare — I moved off Vercel at the same time. Cloudflare Workers gives you unlimited bandwidth with limits that reset daily, and the pricing starts at $5. For a tool that can generate a lot of traffic from a single Reddit post, that’s a much more comfortable place to be than a platform that charges per GB after a free tier.

Reddit and the feedback loop

I posted svglogo.dev on Reddit. Real users showed up, and real feedback followed immediately. Six updates shipped directly from what people asked for.

Mobile support. The desktop-only notice was the first thing people pushed back on. Fair enough — if you’re browsing on your phone and you find a tool you want to use, a wall saying “come back on desktop” is frustrating. I rebuilt the layout to work on smaller screens and removed the notice.

Search all icons on no results. When a search returned nothing in the current icon set, there was a dead end. Someone suggested a fallback: a button to search across all icon sets at once. Simple addition, much better experience when you can’t find what you’re looking for.

Hex input in the color picker. The color picker was visual-only. Several people asked for a hex input so they could paste in a brand color directly. Added it.

Multiple gradient stops. The gradient control started with two stops. People building more complex backgrounds wanted more control — three, four, five stops. Extended the gradient system to support it.

Testimonials. Someone who used the tool to build a logo for their startup shared it in the thread. Then another. Then a few more. I added a testimonials section to the homepage. Social proof built by the community.

Advanced export. Power users wanted more control over the PNG export — custom sizes, padding, scale. Added an advanced export panel with those options.

Every one of these came from reading comments and shipping the same week. That feedback loop is worth more than any amount of solo planning.

What I’d do differently

Ship the sharing feature earlier. It unlocked the social side of the tool — the ability to send a logo to someone for feedback, the shareable URLs that spread the tool around. Everything downstream of it would have been cleaner if I’d designed for it from the start.

localStorage was the right call for collections. I considered adding auth and a real database. I’m glad I didn’t. The tool works without an account. That’s a feature.

Post to Reddit earlier. The six updates I shipped after the Reddit post were better than anything I came up with building alone. Real users with real use cases find the gaps you don’t. The sooner you get in front of them, the faster the product improves.

svglogo.dev is free and open source. If you need a logo for your next project, give it a try. If you find a bug or have a feature idea, the repo is on GitHub.

It started back in 2025 when I wanted to upload files to Telegram. I had many files in Saved Messages, but it was becoming difficult to manage them. I didn’t have a structured way to organize my files.

I wanted a place where I could create folders and upload files, while the content would still be saved in Telegram’s Saved Messages. So I built Drivegram, a file manager specifically for Telegram.

App UI
   ↓
Backend
   ↓
Telegram API
   ↓
Saved Messages storage

What Drivebase Can Do Today

Fast forward today, its now been renamed to Drivebase, and supports not only Telegram but major other storage provider, and slowly adding more in the future as the app grows.

Drivebase evolved from a Telegram file hack into a unified storage layer. Instead of juggling multiple storage apps, Drivebase lets you connect them all in one place and manage them through a single interface.

interface StorageProvider {
  upload()
  download()
  list()
  delete()
}

The experience is intentionally designed to feel like a normal file manager, even though the data may live across completely different providers.

Checkout the website to get started. Or clone the source code from Github.