// Mobile-friendly retrofits

Make your existing web app mobile-friendly, page by page, without a rebuild

When contractors, crews or customers have to pinch and zoom through screens built for a desktop monitor, the work waits until they’re back at a desk, or turns into a call to your office. We make your existing web app or portal mobile-friendly, starting with the tasks people do on the go.

Talk to an engineer about your existing system Try the mobile-friendly test

Example (hypothetical): phone check at 390px

→ open /work-orders on a phone! page scrolls sideways: 9-column table! “Edit” icon is 16×16px; WCAG minimum is 24×24! menu only opens on mouse hover! photo upload has no camera option→ retrofit this page✓ table rows become stacked cards✓ tap targets at least 24×24px✓ upload button opens the camera✓ desktop layout checked before release

// What breaks

What breaks on phones in older web apps

When someone says the portal “doesn’t work on my phone,” check these six things first.

Fixed widths and inline styles

Layouts hard-coded to a desktop width, often written into each page, so the phone shrinks everything until it’s unreadable or scrolls sideways.

Table layouts and wide data tables

Pages laid out with HTML tables, and job, order or invoice lists with ten columns. On a phone, the column that matters ends up off-screen.

Hover-only menus

Navigation that opens when a mouse rests on it. Phones don’t hover, so menus open by accident or not at all.

Tap targets too small

Tiny links and icon buttons packed into tight rows. People tap the wrong record, back out, try again or give up.

Desktop-only interactions

Drag and drop, right-click menus, double-click to edit, and pop-up windows that open off-screen or get blocked.

Logins that fight phone browsers

Forms that block paste, confuse password managers or open the wrong keyboard. When people can’t get in, they call your office.

// Your options

Retrofit, separate mobile site or native app?

For forms, lists and status pages, a responsive retrofit is often the place to start: it can change the screens while leaving the data and business rules behind them alone. Here’s how it compares.

Option

What it means

Good fit when

Watch out for

Responsive retrofit

The pages you already have adapt to any screen. Same system, URLs and logins.

People fill in forms, check status, search lists and upload photos.

Dense, mouse-driven screens may need a phone-specific design, not just new layout rules.

Separate mobile site

A second, cut-down set of pages for phones.

You need a stopgap for one narrow task.

Every change is built and tested twice, and the versions drift apart.

Native iOS or Android app

An app installed from the App Store or Google Play.

Work happens offline for long stretches, or needs scanning, background location or dependable push notifications.

Users have to install and update it, and releases go through app store review.

We build React web apps and native iOS and Android apps, so we have no reason to steer you toward one. Our guide to mobile web apps vs native apps for field teams goes deeper, including installs and device policies for contractors who aren’t your employees.

// Prioritize

Start with the screens people use on the go

A 200-screen system doesn’t need 200 retrofits before anyone benefits. We prioritize by workflow, not page count: a contractor accepting an assignment from a parking lot, a technician uploading job photos before leaving the site, a customer checking an order status after hours. Those screens come first, even if they’re a small slice of the system. For portals, our guide to contractor portal features lists the tasks that matter most on a phone.

Admin settings, reports and setup pages used at a desk can stay desktop-first until later. The same approach works when you need to make a customer or vendor portal mobile-friendly, or an internal tool.

✓Which tasks happen in a truck, on a job site or between appointments?
✓Which screens cause the most calls and emails to your office?
✓Which steps need the phone itself: the camera, a signature, a location?
✓Which admin screens can stay desktop-first for now?

// The technical retrofit

The technical retrofit: tables to cards, breakpoints, tap targets, camera uploads

Converting a desktop web app to mobile responsive is mostly front-end work, done screen by screen.

Wide tables become stacked cards

Each row turns into a card showing the three or four fields people need on the move, such as job, date, location and status, with the rest one tap away. On a desktop the same page still shows the full table.

Breakpoints set by your content, not a device list

We add the viewport tag if it’s missing, replace fixed widths and inline styles with flexible layouts, and set breakpoints where your screens actually break. Hover menus become tap-to-open menus; pop-up windows become panels that fit the screen.

Tap targets a thumb can hit

WCAG 2.2 Success Criterion 2.5.8 sets a minimum target size of 24 by 24 CSS pixels for pointer input, with exceptions such as links inside a sentence. We treat that as the floor and add spacing so people stop tapping the wrong row.

Camera and photo uploads from the phone

An upload field can ask the phone to open its camera directly, using the capture attribute from the W3C’s HTML Media Capture Recommendation. We also plan for large photos, weak signal, visible progress and a clear message when an upload fails, so people know whether a photo went through.

Logins that work with phone keyboards and password managers

Email fields open the email keyboard and code fields open the number pad. Username, password and one-time-code fields carry the standard autocomplete names from the HTML standard, so password managers and the phone’s autofill can fill them. And we don’t block paste.

// Our method

Our method: page by page, on the portal you already have

We’re modernizing Amusement Advantage’s existing contractor portal page by page, each page tested on a staging copy before production, so contractors can register, find and apply for assignments, check status, update info and upload photos from their phones.

Page by page means the most-used screens can improve first, with no single launch day where everyone has to relearn the system. The work continues as ongoing maintenance.

Need your own contractor portal mobile-friendly? See contractor portal development, or read the full Amusement Advantage case study.

Modernization · Contractor portal

A contractor portal made mobile-friendly, page by page

We’re modernizing Amusement Advantage’s existing contractor portal for its network of 60,000+ contractors. Mobile-responsive pages now cover about 90% of the contractor workflow, with 20–30% fewer support requests for login, opportunity search and assignment status.

ModernizationPortalMaintenance

Read the case study →

“

They take the time to truly understand the use case and business need and suggest solutions tailored to our specific needs. Solutions often exceed expectations as to final design and functionality. They are always quick to respond to issues that require urgency and frequently offer help outside the scope of current projects.

Scot Carson

Chief Experience Officer, Amusement Advantage

// Honest limits

When a responsive retrofit isn’t enough

A retrofit changes how screens look and behave on a phone, not what the system can do. Some screens need more than new layout rules, and we’ll say so. Often the answer is a mix: retrofit most screens, rebuild one module. See legacy application modernization for the wider options, or all our services for problems beyond phones.

!Mouse-driven screens, like drag-and-drop schedulers or spreadsheet-style grids, often need a phone-specific design for that module.
!Crews who work for hours without signal need offline storage and sync, which points to a native app or an offline-capable module.
!Barcode or NFC scanning, background location and dependable push notifications lean toward a native app.
!If every change to the code breaks something else, rebuilding that module may be the safer path.

Retrofit or rebuild that module?

Our free rewrite vs refactor scorecard helps you weigh improving the code you have against starting that part over.

Use the scorecard →

// Engagement

How a mobile-friendly retrofit runs

Google retired its Mobile-Friendly Test on December 1, 2023 (Google’s notice), so step one uses a free one we made for web apps.

Step 1

Check your key screens

Run our free mobile-friendly test for web apps on the screens people complain about; its checklist works on any page, logged in or not. Your first call is with an engineer, who can go through the results with you.

Step 2

Prioritize the screens

We list the tasks people do away from a desk and rank screens by phone use and the calls they cause. You get a short, ordered list instead of a whole-system project.

Step 3

Retrofit page by page

We change one screen or a small group at a time, tested on a staging copy before production, the way we’re modernizing Amusement Advantage’s portal. Desktop and phone layouts are both checked before release.

Step 4

Release and maintain

Each page goes live when it’s ready. We keep it working as browsers and phones change, then move to the next screens on the list. You talk directly to the engineers doing the work.

// FAQ

Mobile-friendly web app FAQ

Do we need a native app?

Often not. Forms, status checks, uploads and photos usually work well in a mobile-friendly web app. Native apps earn their cost for things like heavy offline use or device hardware. We build both (React, iOS and Android), so we’ll recommend what fits.

Can you work in our existing codebase?

Yes. A retrofit improves the pages you already have, one at a time, instead of rebuilding the system.

What happens to desktop users?

Responsive pages adapt to the screen, so desktop users keep a full layout, and both layouts are checked before a page is released.

Can you modernize pages behind our login?

Yes. Portals and internal tools are usually behind a login. Our free mobile-friendly test for web apps has a checklist mode that works on any page, plus a bookmarklet that often works on logged-in pages.

What results can we expect?

We can’t promise numbers for your system. For Amusement Advantage, mobile-responsive pages now cover about 90% of the contractor workflow, with 20–30% fewer support requests for login assistance, opportunity search/updates and assignment/project status. The case study has the details.

// Keep exploring

Keep exploring

Free tool

Mobile-friendly test

Google retired its Mobile-Friendly Test. Our free mobile-friendly test for web apps runs in your browser, often behind a login, and flags what breaks.

Use the free tool →

Guide

Mobile web app vs native

Mobile web app vs native app for field teams: decide task by task, from forms and photos to offline work, scanning, alerts and getting contractors started.

Service

Legacy modernization

Legacy application modernization without starting over: page by page, while the old system keeps running. U.S.-based engineers you talk to directly.

// Bring us in

Tell us about the software your business runs on.

A new build, a system that’s hard to use, a stuck project or a prototype that needs to go live. An engineer, not a salesperson, will get back to you.

Talk to an engineer Call (202) 886-2442

202-88-MAGIC · or email info@effortlesspresence.com