How Do You Make a Desktop-First SaaS App Work on a Phone?

How Do You Make a Desktop-First SaaS App Work on a Phone?

Pick the two or three jobs people genuinely do on a phone and build those properly, instead of shrinking the whole application. A dashboard designed for a 27 inch monitor cannot be reflowed into something useful at 390 pixels wide, and trying is how teams spend a quarter and ship something nobody uses.

This request usually arrives as a complaint. Someone senior tried to approve something from a taxi, could not, and now mobile is a priority.

That complaint is more useful than it sounds, because it contains the actual brief. They did not want the app on their phone. They wanted to approve something.

Why Is Responsive Not the Answer Here?

Because responsive design solves layout, and this is not a layout problem. A marketing page has one job and a phone can do that job with a narrower column. A SaaS application has forty jobs, most of which need a keyboard, a large canvas, or sustained attention.

Stacking a data table into cards does not make bulk editing possible on a phone. It makes bulk editing visible and impossible, which is worse, because now people try.

The honest framing is that mobile is a different product surface with a different job list. Once a team accepts that, the work gets much smaller and much more likely to succeed.

Which Jobs Do People Actually Do on Their Phone?

Read, approve, respond, and check. Almost never create, configure or analyse. The mobile jobs are the ones that are short, reactive, and triggered by something else, usually a notification or a message from a colleague.

Find yours from evidence rather than assumption. Look at which pages already get mobile sessions despite being painful, which links get opened on mobile from your own emails and alerts, and what your support team hears. Those three sources agree more often than not.

Then cut ruthlessly. Three jobs done excellently beats twenty done at seventy percent, because the twenty will each fail in a way that teaches people not to open your app on a phone again.

The overall traffic split is worth knowing as context. Statcounter's worldwide figures for August 2026 put mobile at 49.36 percent and desktop at 49.11 percent, so mobile is not a minority platform in general. Your own product's split will be nothing like that, and that is fine. The point is that your users live on phones everywhere else, and they arrive with those expectations.

What Happens to the Data Table?

It becomes a list, and the list answers one question. This is the single hardest conversion and where most mobile efforts die.

A table on desktop lets someone scan many attributes across many rows and compare. On a phone you can show one row's worth of information at a time, so you have to decide what the row is for. Usually there is a primary identifier, one status, one number, and one action. Everything else goes behind a tap.

Filtering and sorting have to be rebuilt rather than reflowed, because the desktop pattern of a filter bar above the table does not survive the loss of horizontal space. What works is one clear entry point that opens a focused filter view, applies, and closes. Our thinking on the desktop side is in designing web data tables, and the mobile version is genuinely a different design rather than a compressed one.

Accept that some tables have no mobile equivalent. A reconciliation view with eighteen columns is not a phone screen and pretending otherwise helps nobody.

How Do You Handle Navigation That Assumed a Sidebar?

Replace it, do not collapse it. A desktop sidebar with fourteen sections becomes a hamburger menu with fourteen sections, which is a list of things a person cannot do on this device.

The better move is a small, fixed set of destinations matching the mobile job list, with everything else reachable but not promoted. If your mobile jobs are approve, respond and check, then that is roughly your navigation.

Workspace or account switching deserves specific thought, because it is a desktop-era pattern that often hides in the sidebar. On a phone it needs to be either prominent, if switching is common, or entirely out of the way, if it is rare. The middle option, buried but present, is the one that causes people to act in the wrong account.

What Are the Non-Negotiable Mechanics?

Touch targets, keyboard behaviour, and state preservation. Get these wrong and nothing else matters.

On targets, WCAG 2.2 sets success criterion 2.5.8, Target Size (Minimum), at Level AA, requiring that the target for pointer inputs is at least 24 by 24 CSS pixels. It lists exceptions, including where sufficient spacing means a 24 pixel diameter circle centred on each target does not intersect another, where an equivalent control on the same page meets the criterion, and where the target is inline in a sentence.

Treat 24 by 24 as the floor for conformance, not the target you design to. The platform guidelines have long recommended more: Apple's Human Interface Guidelines recommend controls of at least 44 by 44 points, and Material Design recommends touch targets of at least 48 by 48 dp, noting that an icon may look 24 by 24 dp while padding makes up the full target. Design to the platform figures and you clear the accessibility floor comfortably.

On keyboards, set the right input type so the numeric pad appears for numbers, and check what your on-screen keyboard does to any fixed footer. On state, a phone user will be interrupted. Losing a half-written response because a call came in is the fastest way to lose the user permanently.

What Should You Deliberately Not Build?

Anything that needs precision, sustained attention, or side-by-side comparison. Drag-and-drop arrangement, multi-select bulk operations, complex form builders, anything with a canvas, and detailed analytics with many dimensions.

The right treatment for these is an honest message rather than a degraded version. A short line saying this view needs a larger screen, with a way to send themselves a link, respects the user far more than a broken interface does. It also stops your support queue filling with reports about a thing you knew was bad.

Being explicit about the boundary is also what keeps the scope from creeping back. Once "we support mobile" is unqualified, every feature request arrives with a mobile requirement attached.

How Do You Decide Between Responsive Web and an App?

Ask whether the jobs need anything only a native app provides. If the answer is push notifications, offline work, camera, or biometric sign-in as a core part of the job, that is an app conversation. If it is none of those, responsive web is almost always the right call.

The reason is maintenance rather than capability. An app is a second product with its own release cycle, review process and support burden, and most teams asking this question do not have the appetite for that once the novelty fades.

The middle path worth considering is a responsive web experience that is installable, which covers notifications and a home screen presence for many use cases without a second codebase.

How Do You Roll This Out Without a Rewrite?

Build the mobile jobs as their own routes rather than retrofitting existing screens. A focused approval view at its own URL is a small, shippable piece of work that does not destabilise the desktop app.

Then point your notifications and emails at those routes. This is the step teams forget, and it is where the value actually lands, because the mobile job almost always starts with an alert. If the alert links to the desktop screen, you have built something nobody will find.

Expand only when usage shows a fourth job appearing. Let demand pull the scope rather than pushing it, which also gives you evidence when someone asks for the whole app on a phone. Progressive disclosure helps a lot here, and we wrote about it in designing with progressive disclosure.

How Do You Know It Worked?

Measure task completion on the mobile routes, not mobile sessions. Sessions go up when people try something and fail. Completion tells you whether the approval actually got approved.

The second signal is where people give up and switch devices. If a meaningful share of mobile sessions end with the same user completing the task on desktop minutes later, your mobile version is a detour rather than a destination. That is the number worth watching for the first few months.

And keep the scope honest in reviews. The question is never whether the app works on a phone. It is whether those two or three jobs work on a phone, better than they did before. Our wider notes on the desktop experience are in what makes a SaaS dashboard usable.

If you are weighing up how much of your product genuinely belongs on a phone, that is a scoping conversation we enjoy. Come and find us at phoenix.studio.