Mobile App Development

The first question isn't what the app should do. It's whether you need an app at all.

A surprising number of "we need an app" conversations end with a mobile-friendly web page, built in a fraction of the time, with no app store, no install, and no update that half your staff never apply.

Sometimes you genuinely do need the real thing. The difference is worth getting right before anyone writes code, because it's the decision that sets the cost of everything after it.

Start with who uses it and where

Who uses it, and where What that points to Your own staff, on company phones, in signal A mobile web app A plant, a warehouse or a truck, patchy signal A cross-platform app Customers, who expect to find you in a store A native app
Most internal business tools sit in the top row. People ask for the bottom row because that's what "app" means to them.

What each route actually costs you

Rough effort, lightest first Mobile web app no store, no install Cross-platform app installed, works offline, one codebase Native app store review, two platforms, the most upkeep forever
The bars are build effort. The gap widens afterwards — a native app keeps costing you every time Apple or Google changes something.

Which one is right for you

A mobile web app is the honest answer more often than anyone wants to hear. It's a web application designed for a phone screen. No store, no install, no approval queue, and when you fix something every user has the fix immediately. If your people are on company phones with a signal, this is usually where to start.

A cross-platform app earns its cost when the phone has to do something a browser can't do well — work with no signal and sync later, use the camera as a scanner all day, or run as a proper installed tool on a device that lives in a truck. One codebase, both platforms.

A native app is for when you're going to customers, when being in the App Store is part of the point, or when you need the device's capabilities at full depth. We build native iOS and Android apps — and we'll still tell you if one of the lighter routes would serve you better, because native is the most expensive route to build and, by some distance, the most expensive to keep alive.

The part that's actually hard

The app is the easy bit. The hard bit is everything it talks to.

A mobile app is a window onto systems you already run — your ERP, your database, your scheduling system. Whether it works depends on whether those systems can be reached safely from outside your network, whether the data coming back is correct, and what happens when a phone has been offline for six hours and comes back with changes that conflict with somebody else's.

That's integration and database work, and it's where mobile projects quietly fail. It's also what we do all day — we administer PostgreSQL, MySQL, Microsoft SQL Server and Oracle, and we write the custom software that sits between them.

Things people forget to budget for

  • Getting it onto the phones. Company devices need a way to install and update it without someone walking round the building.
  • The platforms change under you. New OS versions arrive every year and they don't ask first. An app with nobody maintaining it has a shelf life.
  • Offline is a decision, not a feature. "It should work without signal" means choosing what happens when two people change the same record. That choice is business logic, not code.
  • Who holds the store accounts. Worth agreeing on day one, not at launch.
  • Security on a device that leaves the building. Phones are lost. Plan for it before it happens, not after.

Why Argyle

We're a managed services provider that develops software, which means we're unusually willing to talk you out of an app.

We don't have a mobile team that needs feeding, so there's no incentive to make your problem look like an app-shaped problem. If a web page solves it, we'll build the web page. If it needs more, we'll tell you which route and why, with the running costs attached.

And because we run infrastructure, we're asking the questions that decide whether this works: how does the phone reach the ERP, who patches the server behind it, what happens when the certificate expires. Those are the questions a pure app shop leaves on your desk.

We're in Perrysburg, serving Toledo, Maumee, Sylvania, Bowling Green, Findlay and across Northwest Ohio and Southeast Michigan.

Tell us what the phone needs to do

Describe the job — who's holding the phone, where they are, and what's slow today. We'll tell you which of the three routes fits and roughly what each would cost to build and to keep.

Call 419-419-5737 or send us a message and ask about mobile.

Argyle IT Solutions · 28304 Cedar Park Blvd., Suite A, Perrysburg, OH 43551 · Serving Toledo, Perrysburg, Maumee, Sylvania, Bowling Green, Findlay and all of Northwest Ohio and Southeast Michigan.