When an app is the right call
The honest version: when customers already buy from you often enough that a home-screen icon saves them something, and when you have a reason to send a push notification that a customer would thank you for.
Replenishable goods, subscriptions, loyalty-driven categories and anything with a genuine routine behind it tend to clear that bar. Considered one-off purchases almost never do — nobody installs an app to buy a sofa.
What we build instead, often
If the fit assessment says no, the money is usually better spent on the mobile storefront: speed, search, product pages and checkout friction. That work is measurable in weeks rather than quarters, and it serves all of your mobile traffic rather than the small share who would ever install something.
That is eCommerce development, and it is a cheaper conversation than this one. If an app does make sense, it will still need to read your catalogue and orders cleanly, which is API and integration work.
The real cost of an app is year two
Building it is the cheaper half. Two OS releases a year, store policy changes, SDK deprecations and device fragmentation mean an app needs ongoing budget simply to keep working. We will tell you what that looks like before you commit, because an abandoned app in the store does more brand damage than never shipping one.
Talk it through honestly 
Scope
What a build includes.
-
One catalogue, not two
The app reads the same products, prices and inventory as the storefront through the platform's own APIs. A separate catalogue to maintain is how apps quietly go stale.
-
The platform's native checkout
Shopify or Adobe checkout rather than a bespoke one, so payment methods, tax and fraud rules stay in one place and PCI scope does not expand.
-
Push that is worth receiving
Segmented against real behaviour — back in stock, order shipped, replenishment due — rather than a weekly broadcast that trains people to disable notifications.
-
Store listings that will pass review
Privacy labels, data disclosures, account deletion and the sign-in requirements both stores now enforce, handled before submission rather than after rejection.
-
Analytics joined to your web data
App events in the same analytics property as the storefront, so you can see the whole customer rather than two unrelated halves.
-
A release process your team can run
Build pipeline, signing credentials and store accounts in your ownership, documented, so you are not dependent on us to ship a fix.
How it runs
From first call to live.
- Fit assessment 1–2 weeks
Repeat-purchase rate, mobile traffic mix and what push would actually carry. If the numbers say a mobile storefront serves you better, we will say so at this stage rather than after you have committed.
- Scope and design 3–4 weeks
Which journeys belong in the app and which should stay on the storefront. An app that mirrors the whole site costs twice as much and is used half as often.
- Build 10–16 weeks
iOS and Android from one codebase unless a platform-specific capability genuinely warrants otherwise. Fortnightly builds on real devices, not simulators.
- Store submission 2–3 weeks
Review cycles for both stores, with time budgeted for a rejection. First submissions are rejected often enough that planning for it is realistic, not pessimistic.
- After launch Ongoing
OS releases break apps on a schedule nobody controls. Budget for maintenance from day one; an unmaintained app is worse than no app.
