Michael Audu

Whenever a customer cancels, our first instinct is to look at the feature request board. Ah, we don't have integration X, that's why they left.

But when we actually started digging into exit interviews, the real reason was rarely missing features. It was friction. The tool required too many steps or didn't naturally slot into how their team already communicated.

How do you differentiate between someone genuinely needing a specific features versus your app simply disrupting their existing daily habits in a bad way?

You re halfway through debugging on a remote host.

A command is still running, but you need another shell to inspect a log. Do you reconnect, pass through the jump host again, and find your working directory all over again?

This small interruption is why I added Duplicate Tab to xtty.

• It opens a new, independent SSH connection to the same host.

• It returns to the same remote directory.

• The original session stays exactly where it is.

I've been thinking about this a lot while building our first version.

The product works, and the core experience is there, but there are still some bugs, rough edges, and occasional inconsistencies. Nothing fundamentally broken, but definitely things we already know we could improve.

One side of me thinks we should just launch it, get it in front of real users, and let actual usage tell us what matters. Otherwise, it's very easy to spend weeks fixing things that users may not even care about.

The other side worries that a rough first experience can hurt more than it helps. People might try the product once, hit a bug or see something inconsistent, and never come back, even if the underlying idea is good.