DEV Community: Mohit Gauniyal

What happens when a personal tool accidentally becomes a team tool — and what you have to rebuild

Mohit Gauniyal — Sun, 15 Mar 2026 17:21:04 +0000

A few weeks ago I posted here about a small tool I'd built — Instbyte, a self-hosted LAN clipboard for dev teams. Got some traction, a few people tried it.
What I didn't expect was that the tool itself would change this much in the months after.
I want to write about that process honestly because I think it's a pattern that comes up a lot when you build something for yourself and then other people start using it — the assumptions baked into the original design start breaking in interesting ways.

The original assumption: one person, a few devices
When I built v1 the mental model was simple. One person runs it, shares the URL with a few teammates, they use it for a sprint, it auto-deletes, done. The data model was flat — just items in a feed. The UI was basically a list with a compose box.
This worked. But when teams actually started using it consistently, the flat feed became a problem immediately. Build logs were mixing with design assets were mixing with credentials were mixing with random links. The tool that was supposed to reduce noise was creating its own noise.
The answer was obvious in retrospect: channels. But adding channels to something that assumed a flat structure meant revisiting the database schema, the socket events, the UI layout, and the search implementation all at once. A small conceptual change with a wide blast radius.

The thing I didn't design for: the live session
The original tool was async. Drop something, someone sees it later. That's fine for files and links.
But teams started using it during standups and pair sessions — and suddenly the async model felt wrong. People wanted a shared surface, not a shared history.
This pushed me toward building broadcast mode — a way to push your screen to every connected device simultaneously. Anyone watching can click to capture a screenshot into the shared feed. No screenshare lag, no projector needed.
Broadcast required a completely different architecture decision from the rest of the tool. The rest of Instbyte is store-and-forward. Broadcast is live. I ended up keeping them as separate features that share the same UI rather than trying to unify them, which I'm still not sure was the right call.

White-labelling as a product decision, not a feature
At some point someone asked if they could rename the app for their team. I said sure and exposed the branding config — name, color, logo, favicon, all from a JSON file.
What I didn't anticipate is how much this changes the way people relate to the tool. Teams that white-label it treat it as their own infrastructure, not as "that Instbyte thing." They're more likely to keep it running, integrate it into their workflow, and tell other people about it.
The tradeoff is that white-label means zero brand visibility for me when those teams share it internally. I'm still working out how I feel about that.

The pipe interface — for people who don't want to touch a browser

npm run build 2>&1 | curl -X POST http://192.168.1.42:3000/text -d @-
This was a small addition that turned out to be disproportionately popular with the developer users specifically. Being able to pipe terminal output directly into the shared feed without context-switching is genuinely useful during CI failures, debugging sessions, or any time you want your team to see output as it happens.

I'm considering a proper CLI package to clean this up. Curious whether that's worth the maintenance overhead or whether the curl interface is already good enough for the people who'd use it.

Where it is now
v1.10. MIT licensed. npx instbyte to run it. Docker image available. Everything persists in the directory you run it from.

Full list of what's changed since the first post: channels, broadcast mode, pipe support, passphrase auth, configurable retention, read receipts, pin, undo delete, cross-channel notifications, dark mode, full white-label, QR join, Docker.

GitHub: github.com/mohitgauniyal/instbyte

What I'm actually curious about
Two things I genuinely haven't resolved:
First — the broadcast feature gets less usage than I expected relative to how much work it took to build. I think it's a discoverability problem but it might be that the problem it solves isn't as common as I thought. If you run standups or design reviews, does "push to every screen in the room simultaneously without screensharing" solve something real for you?

Second — the white-label tradeoff. If you've built something that people use internally under their own branding, how do you think about visibility vs adoption? Is invisibility just the cost of being genuinely useful infrastructure?

Building a shared clipboard for dev teams — looking for feedback

Mohit Gauniyal — Mon, 02 Mar 2026 08:47:33 +0000

I built a tool for sharing things instantly across devices — it's now something my dev team uses daily

It started small. I was running something on localhost and wanted to quickly check it on my phone. Typed the IP, added the port, hoped for the best. Did that enough times that I thought — why not just build a proper UI for this?

So I did. And then I kept adding things.

What started as a personal convenience tool has quietly become something my team reaches for during almost every sprint. This post is about how that happened, what it actually looks like in practice, and where I want to take it — because honestly I want feedback from other devs on what's missing or what could be better.

What it is

Instbyte is a self-hosted local network sharing tool. One command on any machine:

npx instbyte

A URL appears. Anyone on the same network opens it in their browser. That's it — no install on their end, no account, no cloud. Everything syncs in real time.

You can share files, text snippets, links, API payloads, logs, build artifacts — anything. It all lives in channels, auto-deletes after a configurable retention window, and never leaves your network.

How it actually gets used in a team

This is the part I want to talk about more than the technical stuff, because the use cases kind of surprised me as they emerged.

Sharing payloads and logs mid-sprint

Someone hits an unexpected API response. Instead of copy-pasting it into Slack, screenshotting it, or trying to describe it — they drop it into Instbyte. Everyone on the sprint who has the URL open sees it instantly. We can all look at the same JSON at the same time without anyone forwarding anything.

Same with logs. A long error trace is awkward in a chat message. Drop it in, it renders with syntax highlighting, everyone can read it properly.

Build files between machines

I have situations where something is built on one machine and needs to get to another quickly. Drag it onto the page, it's there. The person on the other machine clicks it, it downloads. No USB, no cloud upload, no "I'll send it to you on WhatsApp."

For larger files — the default cap is 2GB — it shows a progress bar during upload so you know it's moving.

During standups and pair sessions

This one snuck up on me. When you're pairing or in a standup and someone says "here's the endpoint" or "use this token for testing" — instead of DMing it or putting it in a shared doc that you have to find later — it just goes into the general channel. It's there, everyone on the call can copy it, it disappears after 24 hours anyway so it doesn't clutter anything.

The paste-anywhere behaviour helps here too. You don't have to click into an input — paste anywhere on the page and it sends. When you're mid-conversation that small thing actually matters.

Moving assets between designers and devs

Drop an image, a mockup, an icon export — it previews inline. No "did you get the file I sent" back and forth. It's there, you see it, you download it if you need it.

The features that make it feel like a team tool rather than a file drop

A few things I've added that changed how it feels to use:

Channels — keeps things from becoming a single noisy feed. We have general, builds, assets, and a temp channel for things that definitely don't need to survive the day.

Read receipts — shows how many devices have actually viewed each item. Small thing but genuinely useful when you've dropped something and want to know if your teammate saw it before the standup.

Expiry badges — items show a countdown to when they'll auto-delete. Keeps the mental model clean. Nothing lingers. If something needs to stay, you pin it.

Inline editing — update a snippet in place without deleting and re-pasting. Useful when an endpoint changes mid-sprint and you want to correct what's already there.

Passphrase auth — if you want to lock it down so only your team gets in, one line in the config file.

White-label — set a custom name, colour, logo. We run it as "Team Hub" internally. Sounds small but it makes it feel like yours rather than a random tool you're running.

Running it

**npx instbyte
**```
{% endraw %}


Or globally:
{% raw %}


```bash
npm install -g instbyte

For persistent team use, throw it behind pm2:

pm2 start "npx instbyte" --name instbyte

Config is optional — everything has sensible defaults. If you want to customise:

{
  "auth": { "passphrase": "yourteampassword" },
  "storage": { "maxFileSize": "2GB", "retention": "24h" },
  "branding": { "appName": "Team Hub", "primaryColor": "#7c3aed" }
}

Drop that as instbyte.config.json in the directory you run from. That's it.

Where it's at and where it's going

Currently at v1.9. It's MIT licensed, open source, built on Node.js, Express, Socket.IO, and SQLite.

v2.0 is where I want to make it easier to run without Node at all — Docker image, standalone binaries for macOS, Windows, and Linux. The goal is that anyone on a team can run it with one download regardless of their setup.

But before I get there I genuinely want to hear from other developers using it or considering it. What's missing for your workflow? What would make it something you'd actually keep running on your machine? What's confusing, what's unnecessary, what's the one thing that's not there?

GitHub: https://github.com/mohitgauniyal/instbyte

npm: https://www.npmjs.com/package/instbyte

npx instbyte

TabLedger — Iteration 3 (Now It Actually Feels Usable)

Mohit Gauniyal — Wed, 25 Feb 2026 07:58:00 +0000

A few weeks ago I wrote about building a tiny Chrome extension because I was drowning in tabs and did what devs do best — built a tool instead of fixing the habit.

Since then, I’ve been using it daily.

And as expected, the real improvements didn’t come while building it — they came while using it.

v0.0.3 is now out, and this version is less about “saving tabs” and more about actually managing them properly.

What changed in v0.0.3?

Proper Snapshot Management Saved sessions now have a structured dashboard instead of just being dumped in a list. It feels like something you can actually work with.

Search Across Snapshots You can search by snapshot name or even URL keywords. This was a big one. If you save often, scrolling doesn’t scale.

Domain Filtering (with quick chips) Filtering by domain makes it much easier to find context-specific work. If I was researching one tool across multiple sessions, I can now isolate that quickly.

Safer Save & Close Pinned tab protection + confirmation flows. No accidental nuking of important tabs.

There are smaller UX refinements too — rename snapshots, copy individual links, safer deletes — but the main goal was reducing friction.

Still:

No accounts

No cloud sync

No tracking
Everything stays local in your browser.

It’s still intentionally simple.
But now it feels stable enough to actually rely on.

Repo:
https://github.com/mohitgauniyal/tabledger

Would love to hear how others manage tab overload — I’m already thinking about what v0.0.4 should look like.

Tab overload, built a snapshot tool (classic dev move)

Mohit Gauniyal — Mon, 02 Feb 2026 15:24:19 +0000

Like many here, I end up with way too many tabs/windows open in Chrome, and my “save for later” links never get revisited

I used to group tabs, move them into another window, or dump links into a file… but it never really solved the “I’ll come back to it” problem.

So I built a tiny Chrome extension to save tab snapshots and reopen them anytime.

Didn’t even research other tools (classic dev ego).
It’s already working great for me, but I’m sure there’s a better way to do this.

How do you manage your tabs? Anything you’d want in something like this? I already have some more updates on my mind once the extension gets approved in google dev dash.

Btw, feel free to checkout and leave your suggestions, always welcome!