Why I Test Every RAXXO Tool on My Phone Before My Desktop

The Habit I Had Backwards

For a long time I built and tested everything in the same order: open the code editor on a wide monitor, ship the feature, check it on desktop, call it done. If I had time left over, I would open it on my phone to confirm nothing was broken. That last step felt like a formality, a quick glance rather than a real check, because the tool had already passed on the screen I spent most of my day looking at.

The problem with that order is that the desktop is the most forgiving screen there is. Extra padding does not matter when there is space to spare. A button that is slightly smaller than it should be is still easy to click with a precise mouse pointer. Text that wraps awkwardly at narrow widths never shows up because the window is never narrow. Every mistake that a small screen would expose gets absorbed by the size of a big one, which means desktop-first testing is really desktop-only testing wearing a disguise.

I noticed this the hard way, not through a single dramatic failure but through a slow accumulation of small ones. A support message here about a button that was hard to hit. A review there that mentioned the site felt cramped on a phone. None of them were urgent enough on their own to stop what I was doing, so I patched each one individually and moved on, the same reactive pattern I try to avoid everywhere else in the studio, including the check I run on every tool before I call it shipped. It took stepping back and counting the pattern to see it was one habit producing many small symptoms, not many unrelated bugs.

Once I actually counted, the pattern was hard to unsee. Nearly every layout complaint I could remember, going back across several releases, traced back to a screen narrower than the one I had tested on first. None of them were dramatic on their own, which is exactly why I had been treating them as isolated. A slightly cramped heading is not a crisis. A pattern of slightly cramped headings, repeated across every tool I ship, is a process problem, and process problems do not fix themselves one patch at a time. They need the order of operations to change, not just the individual bugs.

Flipping the Order

The fix was not a new checklist item, it was reversing the order of two steps I already had. Now the phone comes first. Before I touch a desktop browser, I open whatever I am building on the smallest screen I test on and use it the way an actual customer would on their actual device, scrolling with a thumb, tapping instead of clicking, reading at whatever size the screen actually renders at rather than the size I imagine it at while looking at a monitor three times as wide.

This changes what gets built, not just what gets checked. When the phone is the first screen a layout has to survive, I stop being able to rely on space I do not have. A row of five buttons that fits comfortably on a desktop has to either shrink to the point of being unusable or restructure into something that works in a single column. Testing phone-first forces that decision to happen at design time, while the layout is still cheap to change, instead of at bug-fix time, after customers have already run into it.

It also changes how I write copy. A paragraph that reads fine at desktop width often turns into an intimidating wall of text at phone width, where the same number of words wraps into twice as many lines. Once the phone became the first screen I looked at, I started cutting sentences that used to survive because they looked reasonable on a wide layout. Short sentences are not just a writing preference, they are a testing outcome. The screen that shows the least forgives the least, and that pressure is useful.

There is a smaller, quieter benefit too. Testing on a phone first means I am usually away from the keyboard, holding the device the way a customer actually would, rather than sitting at the same desk where I wrote the code. That small physical shift breaks the illusion of familiarity. Code I just wrote feels obvious to me because I know exactly what every element is supposed to do. A stranger holding a phone does not have that context, and stepping away from my desk to test is the closest I can get to borrowing their perspective before they ever see the real thing.

Where the Old Habit Still Hides

Flipping the order for new builds was the easy part. The harder part was admitting that plenty of already shipped tools still carried the old habit baked into their bones, not just their surface. A layout that was designed desktop-first and only patched for mobile afterward behaves differently from one that was designed mobile-first from line one, even if both eventually look fine on a phone screen. The patched version tends to have more edge cases, more places where a fix for one screen size quietly broke something at another.

Going back through older work with a phone-first eye turned up things a quick glance had missed the first time around. Some of it lined up with the same territory as the accessibility pass every RAXXO section gets before it ships, because a tap target that is hard to hit with a thumb is often the same tap target that is hard to reach with a keyboard or a screen reader. Small screens and assistive tools both punish the same kind of sloppiness, just for different reasons, and fixing one class of problem tends to improve the other almost for free.

The onboarding flow for one of the desktop menu bar tools was the clearest example. The tool itself lives entirely on a computer, no phone involved once someone is actually using it day to day, so it would have been easy to assume phone testing did not apply. But the landing page that convinces someone to try it in the first place is read on a phone as often as anything else I publish, and that page had never been rebuilt with a phone-first eye. It took a real pass, the same kind described in the onboarding screen I rewrote three times for OhNine, to bring the page that sells a desktop tool up to the same phone-first standard as everything else.

The Rule That Has No Exceptions

The instinct to skip phone testing gets strongest exactly where it seems most reasonable to skip, on tools that are obviously meant for a keyboard and a bigger screen. A terminal-based tool or a menu bar app is never going to be operated from a phone, so it is tempting to treat phone testing as irrelevant there and save the time. I used to think that way, and it was a mistake, because the tool itself is only part of what customers experience.

Every RAXXO tool has a page that describes it before anyone downloads or opens it, and that page has no exemption from being read on a phone regardless of what the tool underneath does. Someone finds a link in a search result or a social post, taps it on their phone, and decides in a few seconds whether the thing being described is worth their attention. If that page is slow, cramped, or hard to read at that size, the tool underneath never gets a chance to prove itself, no matter how good the actual desktop experience turns out to be. The first impression is mobile even when the product is not.

So the rule stopped having exceptions. Every section I build gets opened on a phone before it gets opened on anything wider, whether the thing it describes lives in a browser, a terminal, or a menu bar. It costs a few extra minutes per feature. What it buys back is not having to patch the same category of mistake three separate times after customers already found it for me.

Bottom Line

Testing order sounds like a small detail, the kind of thing that should not matter as long as every screen size eventually gets checked. In practice, the order determines what problems are even visible to catch. Desktop-first testing lets sloppy layouts and long sentences survive because the biggest screen absorbs the mistakes silently. Phone-first testing does the opposite, it surfaces the mistake before a single customer has to.

The bigger shift was realizing the rule applies past the obvious cases. It is easy to agree that a shopping page should work well on a phone. It is less obvious, until you feel the cost of skipping it, that a terminal tool's landing page needs the exact same discipline, because the landing page is where every customer meets the product first regardless of what device runs the product itself. Flipping one habit, test small before wide, turned out to fix more than the layouts. It changed how much I let myself write, and how much I let a screen forgive before I ship anything.