Making UX awesome — what separates a semi-serious project from the best.

A friend once told me it was "nice that you're working on a semi-serious project like this." He meant it as a kindness. It stung, and it was right — and it sent me down a rabbit hole I'm still in. This is a note on what I found there: that the distance between a semi-serious project and a real one isn't a feature list. It's the thousand small frictions nobody ever screenshots.

I'd been building VirtuProbe for a couple of years when he said it. We were talking about something else entirely, and it just fell out of him — warm, offhand, not unkind. Semi-serious. A nice thing to tinker on. And I nodded, and I changed the subject, and it lodged somewhere and wouldn't leave.

Because he was right. I'd built a tool that did a lot — nine hand-rolled protocol stacks, chaining, a MITM proxy, fuzzing — and it did all of it with the manners of a hacking toy. It worked if you already knew where everything was and didn't mind the app fighting you a little on the way. It was a haX0r project with a serious engine bolted inside. And the gap between that and something an engineer would trust with their working day is enormous, and almost none of it is on the feature list.

The bar I already knew

Here's the awkward part: I knew exactly what good felt like. I'd spent the better part of fifteen years living inside IntelliJ IDEA. When you spend that long in a genuinely world-class tool, it rewires you. You develop a physical intolerance for friction — a small, involuntary flinch when a dialog opens without focusing its field, when a keyboard shortcut you reach for on reflex isn't there, when the app makes you use the mouse to do a thing you were mid-thought about.

I'd been extending that intolerance to every tool I used and, somehow, exempting my own. So we — and it's we now, a small team builds this with me — decided to stop exempting it. To hold VirtuProbe to the bar we hold everything else to. Not "add polish" as a sprint at the end. Treat friction as a bug, the same class of bug as a crash, and go hunting.

The frictions nobody screenshots

Almost none of what followed makes a good marketing screenshot. That's rather the point. Here's a sample of the last few releases, all of it real, most of it invisible until it's missing.

The focus ring. When you tab into a field, the border should light up — cleanly, following the rounded corner, not cutting a second sharp rectangle inside it. Getting that right took a specific, ugly fix: the browser's default focus outline draws a flat box on the inner input, which has no border radius, so it appears as a second neon border inside the field's rounded outline. So we suppress it and paint the neon onto the four outline segments directly — and carefully not onto the label, so the colour doesn't bleed across the little notch the floating label sits in. There is a paragraph of comments in the stylesheet explaining why. Nobody will ever notice this is correct. Everybody would notice if it were wrong.

Focus and the keyboard. Every dialog now focuses its first field the moment it opens, and Enter submits it — so "new project", "rename", "create probe" are type-type-Enter, no reach for the mouse. Open a probe and the cursor lands in the URL field, ready. And the whole app answers to the keyboard: F1–F8 jump between views, Ctrl+S saves, Ctrl+Enter sends or runs, Ctrl+Shift+F is search. The shortcut is printed right there in the button's tooltip, and it shows ⌘ instead of Ctrl if you're on a Mac, because being told the wrong key is worse than not being told at all.

Never quietly lose work. Edit a probe, try to navigate away, and the app stops you with a real choice — Save, Save as a copy, Discard, or Cancel — rather than silently keeping or dropping your changes. A small dot marks anything unsaved. It's the least glamorous feature we shipped and one of the ones I'd fight hardest to keep.

Empty screens that teach instead of smirk. Early on, an empty panel in VirtuProbe would say something like "a probe won't open itself." Cute. Useless. Actively worse than nothing when you're new and genuinely stuck. Every empty view now carries a short, plain "here's how this works" panel instead — Bundles, Chains, Scripts, the Library, the proxy. The joke went in the bin. The help stayed.

Density, and letting you tune it. The whole interface got tighter — compact controls, more on screen at once, the way a tool you stare at all day should be. And because one density doesn't fit every screen or every pair of eyes, the font face and size are yours to set, from twelve pixels up.

The response, actually readable. An HTTP response now opens onto a status bar that tells you the things you always reach for — the colour-coded status code, the round-trip time, the body size, the content type — then a tabbed panel: Body with a Pretty / Raw / Preview toggle and syntax highlighting for JSON, XML and HTML, and a searchable Headers table. And when a request never gets far enough to become a response — a reset, a timeout, a half-open socket after you sent it something deliberately malformed — it says exactly that (RST, TIMEOUT, EOF) instead of a shrug. On the wire, how it failed is usually the whole answer.

The script editor, and the moment it clicked

If one thing in the last stretch of work captures the shift, it's the script editor. It used to be a plain text box — type your Groovy in, hope for the best, run it, read the stack trace. Now it's a real code editor. Syntax highlighting that follows your theme. Live error checking that underlines the mistake as you type, before you run anything.

And the autocomplete knows your workspace, not just the language. Type vp.send(" and it offers your actual bundle and probe names. Ask for an extractor and it lists the ones that protocol actually has. Type {{ and it completes your environment variables. That's the IntelliJ lesson, transplanted: the tool should know the shape of your work and meet you halfway. Ctrl+S saves, Ctrl+Enter runs. Of course they do.

That was the moment it stopped feeling semi-serious to me. Not a feature I'd added — a standard I'd finally started meeting.

Where this is going

The thread running through all of it is that VirtuProbe should feel like an editor, because that's the shape of tool its users already trust. So the piece landing right now pulls it together: one Project Explorer down the side — your bundles, chains and scripts in a single tree, on every screen — and browser-style editor tabs across the top, remembered per project. Whole views open as tabs too, once each, so you can't end up with three copies of the dashboard. There's even an Alt+F1 to reveal the thing you're editing over in the tree. The comment next to it in the source just says IntelliJ parity, which tells you where our heads are.

None of this is finished. It's the nature of the work — friction is a renewable resource, and there's always another dialog that opens a beat too slow, another empty state that could say something more useful. Which is the other half of the point.

Tell us where it still hurts

We care about this stuff to the point of it being a mild character flaw, and the fastest way to earn our attention is to tell us where the app still fights you. So we put a Feedback item right in the app menu — pick a type (bug, feature request, or just a thought), write what's bothering you, send. No account, no ticket portal. And the Discord is one click away in the corner if you'd rather just say it out loud. The small frictions are exactly the ones that never make it into a formal bug report — so those are the ones I most want to hear about.

A friend called it semi-serious, and he did me a favour. The engine was never the thing standing between VirtuProbe and being taken seriously. The thousand small things were. We're still closing them, one flinch at a time.

Jakub Stonavský is the founder and maintainer of VirtuProbe Studio, based in Prague — and spent fifteen years inside IntelliJ IDEA learning what world-class UX feels like before daring to aim for it. More about the project and how to reach me →