E-commerce and shopping app development

What an app does that your mobile website cannot

An installed shopping app is not a faster version of your store. It is a second surface with four things a browser tab does not have: an identity that survives between visits without a login screen, a position on the home screen, notifications you have been given permission to send, and enough held on the device that the app opens to something useful before the network answers. Each of those is only worth paying for if the same people buy from you often. Someone who orders twice a year will not install anything. Someone who reorders every fortnight is a different proposition.

The rest of this page follows from one decision. The app shares the commerce operation you already run rather than replacing it, so your catalogue, your stock figures, your customer accounts, your orders and your fulfilment stay where they are, and the app becomes another client of them. That is what makes this a custom build scoped to your systems rather than a packaged app we resell, and it is why the system questions come before the screen questions.

Which system owns the catalogue, stock, customers and orders

Before anyone draws an interface, write down the source of truth for six things: products and their variants, prices, stock, customer identity, orders, and fulfilment status. For each one, name the system that owns it, the person allowed to change it, and what is supposed to happen when two systems disagree. That exercise decides whether the app reads a figure or sets it, which side has to be corrected when a number is wrong, and how much of the work is integration rather than interface. If a website already runs your catalogue and search, the app should read the same data rather than keep a second copy that quietly drifts out of step.

Whether a connection is possible at all depends on four things outside the app: whether an interface exists, who can grant access to it, whether the data is clean enough to rely on, and what the provider's terms allow. Confirm those before they enter a scope rather than after. A hosted commerce platform usually publishes an interface an external system can read and write against. A spreadsheet and a chat group do not, and that gap is where app budgets disappear. If you are still deciding how the store itself should be built, e-commerce website development is the page for that decision.

One app sharing one commerce backend

The table below works one shopping journey through three steps, using a fictional shop whose app shares a single commerce backend. The actors, the policies and the responses are assumptions made for illustration rather than a description of how your business runs or of a system we have built. The last column lists evidence to collect before sign-off, which is to say tests still to run rather than tests already passed.

Cart, submitted checkout, payment outcome and the recorded order

Four things get treated as one, and that causes most of the trouble. The cart is a working list held by the app. A submitted checkout is an intention. A payment outcome is a message from a gateway that can arrive late, twice or not at all. The recorded order is what the commerce backend actually holds, and it is the only one of the four that counts. Agree a single identifier that ties a payment attempt to exactly one order, name the system that is authoritative when they disagree, and make sure the app never presents an unconfirmed order as complete. The deeper mechanics belong with payment and checkout.

Where the money is taken is a platform policy question as well as a commercial one. Apple's App Review Guidelines, read on 18 September 2026, state that an app enabling people to purchase physical goods or services that will be consumed outside of the app must use purchase methods other than in-app purchase, such as Apple Pay or traditional credit card entry. That is Apple's guidance for its own store on the date we read it, not legal advice, and both stores revise their rules. If part of what you sell is consumed inside the app, check the current wording before the payment design is fixed.

Notifications are a permission, not a channel you own

Push is the capability most often used to justify an app, and the one most often assumed. Android's documentation, read on 18 September 2026, describes a runtime permission for sending notifications introduced in Android 13, and states that if the user declines it the app cannot send notifications unless it qualifies for an exemption. The same page recommends asking in context, at a moment the person has created, and gives submitting an order for food delivery as an example of that moment. It is Android-specific guidance on the date we read it, and iOS handles the question differently.

Two consequences for scope. Order status has to be readable inside the app whether or not the permission was ever granted, so a refused prompt costs you a channel rather than a feature. And the prompt itself is a design decision: asking on first launch, before the customer has any reason to want a message from you, is the fastest way to lose it permanently. Be honest about what push then does. It can bring somebody back to an abandoned cart or tell them a parcel is out for delivery. It cannot make anyone buy, and we will not put a retention figure in a proposal. Decide which events justify a message and which belong in the order screen alone, because frequency has a price and the price is uninstalls.

Design the failures before you design the happy path

A demonstration of the normal path proves very little, because the normal path is the easy half. The exceptions worth scoping are known in advance: a price or stock figure that was cached and is now wrong, an item that sells out between payment and allocation, a shopper who taps pay twice, a gateway that answers a minute late or never, a notification permission that was refused, and a customer who wants to send something back. Each needs four things agreed: who owns the decision, what the customer sees while it is unresolved, which identifier reconciles the records afterwards, and what evidence you will collect to accept it. They belong in the scope, written as tests to run.

What to bring to a scoping conversation

Four things make a first conversation useful: the commerce systems you run today and who administers each of them, one real order that went wrong and what it took to put right, roughly how often a typical customer buys from you, and any constraint you already know about, such as a stock system that cannot change. We will tell you which parts look solid, which need confirming before anything could be built, and whether the honest answer is a better mobile store instead of an app.

Mobile app development covers the decisions that apply to any app whatever it does. If you would rather start from the systems, the core systems we build lists the pieces that usually sit behind a shopping app, and a scoped enquiry is the quickest route to a real answer.