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?
Top comments (0)