Do we need a native app, or is a good mobile website enough?
For first-time and occasional shoppers, a fast mobile website almost always wins, because there is no install step between intent and purchase. An app earns its place when you have a repeat customer base and need something the web cannot do well: a loyalty identity that is always present, push as a direct channel, offline-tolerant in-store use, scanning, wallet passes, or device features. If your traffic is mostly new visitors and your repeat rate is low, we will tell you to fix the mobile web experience first. Building an app for an audience that will not install it is an expensive way to learn that.
React Native, Flutter, or fully native?
Flutter or React Native for the large majority of retail apps, because the screens are shopping, account, loyalty, and content flows where a shared codebase halves the build and maintenance cost with no experience penalty. We recommend fully native when the app depends heavily on platform-specific capability such as demanding camera or scanning performance, deep wallet and NFC integration, or specialised accessibility work. The decision belongs to the feature set, and we make it in the first phase rather than defaulting to whatever is most convenient to staff.
How does the app stay consistent with our website and stores?
By treating the app as one more consumer of the same commerce services rather than a parallel implementation. Catalogue, pricing, promotions, stock, cart, orders, and loyalty balances all resolve through shared APIs, so a basket started on the app and finished on the site is the same basket, and a price rule changes in one place. Where an app reimplements pricing or promotion logic locally, the two channels drift within weeks and support ends up arbitrating which one was right.
Can the app show whether an item is in stock in a specific store?
Yes, and how honestly it does so depends on your inventory data. If store stock is accurate and available in near real time, you can show availability directly. Where counts are less reliable, we recommend showing an availability band rather than an exact number, or offering a reserve-and-confirm flow where the store validates before the customer travels. Displaying a precise number you cannot stand behind produces wasted journeys and complaints, so the display should reflect the true confidence in the data.
How is loyalty handled in the app?
The app becomes the identity and the wallet: membership credential, points or tier balance, available rewards, personalised offers, and transaction history, all reading from the same loyalty engine the POS and website use. That single source is the point, because a customer who sees one balance at the till and another in the app stops trusting the programme entirely. Where loyalty logic does not yet exist as a shared service, that work usually sits in the retail CRM and loyalty engagement rather than inside the app project.
Can customers scan and pay in store with the app?
Yes, and it is one of the strongest reasons to build one. Scan-as-you-shop with in-app payment removes the queue, and it needs careful design around barcode handling, weighted and age-restricted items, loss prevention checks, and an exit validation step your store teams accept. It also has to tolerate poor in-store connectivity, which means local basket state that survives signal loss and reconciles cleanly. This is a store operations project as much as a mobile one, and we scope it with the store team involved from the start.
How do you approach push notifications without driving uninstalls?
By treating push as a limited budget rather than a free channel. Notifications tied to something the customer is already engaged with, such as order status, collection readiness, back in stock on a watched item, or an expiring reward they hold, are welcome. Generic promotional broadcasts are the fastest route to notifications being disabled, after which you have lost the channel permanently. We implement frequency caps, category-level preferences, and per-campaign measurement of uninstall and disable rates, not just open rates.
Is there an app for store staff as well?
Often, and it can be the higher-return build. An associate app gives the shop floor stock lookup across locations, price and promotion checking, click and collect picking, transfers and receiving, task lists, and endless-aisle ordering for items not in the store. It shares the same service layer as the customer app, and it removes the pattern where staff walk to a back-office terminal to answer a question a customer asked thirty seconds ago.
How long does a retail app take to build?
A focused first release covering browse, account, loyalty, and either checkout or click and collect is typically twelve to twenty weeks on a cross-platform stack, including design, integration, store submission, and a soft launch. Scan and pay, complex personalisation, or an associate app alongside it extend that. The main variable is rarely the app itself: it is whether clean commerce, stock, and loyalty APIs already exist. Where they do not, that integration work dominates the timeline and we say so at estimate stage.
Who handles App Store and Play Store submission?
We do, including store listings, privacy declarations, data-use disclosures, review responses, and the resubmission cycle when a reviewer raises something. Both stores have specific requirements around account deletion, payment mechanics, tracking disclosure, and permission justification that are cheaper to design for than to retrofit after a rejection. We build the release pipeline so subsequent versions ship on a routine cadence rather than as an event.
What happens after launch?
Retail apps need continuous work, because they sit on two operating systems with annual releases, a device fleet that shifts constantly, and seasonal peaks that must not be met with an unmaintained build. We plan for OS compatibility updates, crash and performance monitoring against real device data, funnel measurement to find where purchases are being lost, and a regular release train. An app left untouched for a year drifts into instability on new devices and starts losing conversion silently.
