Mobile website or iPhone app: which should your business build?

Smartphones are still a minority of US phones, somewhere around a fifth to a quarter, but their owners use the web constantly. Mobile is already a noticeable share of traffic for restaurants, retail, real estate, travel and anything with an address. Check your Google Analytics: under Visitors, the Mobile report tells you what share of your visits came from phones last month and from which devices. For many local businesses it is already 3 to 8 percent and climbing every month.

Three platforms matter in the US right now: iPhone, Android and BlackBerry. Windows Mobile is fading, Palm's webOS is small, and Windows Phone 7 is not out yet. BlackBerry still has the largest installed base among business users; iPhone and Android have the heaviest web usage.

The right question is not "which is better" but "what does the customer need to do, how often, and where do they start." If they start at Google, build the website. If they start by opening an icon every day, build the app.

Build a mobile website this year if any of these are true:

• People search for your business, category or location on their phones.
• The main mobile tasks are finding you, calling you, checking hours or prices, reading a menu, or getting directions.
• You do not have a budget to maintain software across iOS, Android and BlackBerry.
• Your current site uses Flash, which iPhone and iPad do not display at all.

Build a native app in addition if you can answer yes to most of these:

• Customers would use it weekly or more (ordering, account balance, loyalty, scheduling, tracking).
• It needs the camera, barcode scanning, GPS in the background, offline access or push notifications.
• Your customers are concentrated on one platform, which you know from your analytics.
• You have the money to build it properly and to update it when Apple ships iOS 4 this month and when Android moves from 2.1 to 2.2.
• There is a marketing plan to get it downloaded. An app nobody knows about is an expensive icon.

A reasonable middle path is a well-built mobile website now, then a simple app for one specific repeat task once the data shows demand. A pizza chain's online ordering, a bank's balance check and a gym's class schedule meet the test. A law firm's brochure does not.

Keep the first version to what a person standing on a sidewalk needs.

1. Click-to-call phone number at the top of every page, using a tel: link.
2. Address with a link to Google Maps for directions.
3. Hours, today's prominently.
4. The three to five things people actually look for: menu, services and prices, inventory search, booking, current promotions.
5. A link to the full site for everything else.
6. No Flash, no popups, no 400KB header image. Aim for pages under 100KB; many users are still on EDGE or paying by the megabyte.
7. Large tap targets and a single-column layout. Fingers are not mouse pointers.
8. Detection or a clean m. subdomain so phones land on the mobile version and desktops do not.
9. Analytics, so you can see what mobile visitors do.

Approaches range from a WordPress plugin such as WPtouch (free or near it) for a blog-based site, to a hand-built mobile layout using CSS and device detection, to platforms such as Mobify or dotMobi tools. Test on a real iPhone, a real Android phone and a BlackBerry, not just a desktop browser resized.

• Start with one platform. In the US that is usually iPhone, unless your analytics say otherwise. The iPad shares the iOS code base but needs its own layout to be worth shipping.
• Budget for the backend. The app is the visible part; the server that holds orders, accounts or inventory is usually the larger cost.
• Plan for Apple's review. Approval takes a few days to two weeks and can be rejected for guideline issues. Read the Human Interface Guidelines before design starts.
• Price it free. A business app that charges $0.99 to access your own store will not get downloaded.
• Keep the mobile website anyway. Search traffic still lands there, and it is where you tell people the app exists.
• Expect ongoing cost. New iOS versions, new screen sizes (the iPhone 4's Retina display doubles image requirements) and bug fixes mean an app is never finished.

Building an app because a competitor did, without a repeat task to justify it.

Shipping a "mobile" site that is the desktop site shrunk, with a phone number that cannot be tapped.

Ignoring BlackBerry when your customers are corporate buyers who carry one.

Blocking mobile users from the full site. Always give them a way through.

No measurement. If you cannot say how many calls and bookings came from phones, you cannot decide what to build next.

We start with discovery: your analytics, your customers' devices, and the two or three tasks they really need to do on a phone. We plan the smallest version that solves those tasks and agree how success will be measured. We build it to work across devices, with our web development and UX and conversion design teams working from one plan, and we connect it to your tracking so brand, growth and technology decisions come from the same numbers. Then we improve: an app only enters the plan when the data says a repeat task is there.

In a representative launch engagement, a regional restaurant group wanted an iPhone app and had a quote for one in hand. The analytics showed mobile visitors were mostly looking for locations, hours and the menu, split across iPhone, Android and BlackBerry. We built a fast mobile website with click-to-call, maps and a tap-friendly menu first, measured for a quarter, and then scoped a simple app around the one repeat behavior the data supported. The website served every device from day one and the app was built for a reason rather than a trend.