Ecommerce app development: whether your store needs an app at all, the four kinds of build, and the handover terms that decide if it stays yours

An ecommerce app development company will build you a mobile app for your store. The question worth answering before you brief one is whether an app is the right thing to buy, because an app has to be installed before it can do anything, and an installed app that is opened twice a year is worse than a fast mobile website. Apps earn their place on repeat purchase frequency: a store whose customers buy monthly can justify one, and a store whose customers buy twice a year almost never can. Everything below is written to help you reach that decision honestly and then buy the build without losing control of it.

The test that settles it

• How often does a customer buy? Weekly or monthly purchasing, subscriptions, reorders of consumables, or a loyalty mechanic people use at a counter: an app has something to do. Once or twice a year: it does not.
• What does the app do that the site cannot? Push notifications you have earned the right to send, a scan at the till, an offline catalogue for a trade customer, saved reorders, a wallet pass. If the honest answer is nothing, the app is the site in a shell.
• Who installs it, and why would they? The install is the barrier. Count the customers you could realistically ask, in the places you could ask them: packing slips, receipts, the counter, your email list.
• What is the mobile site like today? Fix the slow pages, the checkout and the search on the site you already have before paying for a second storefront. That work benefits every visitor rather than only the installed few.

Write those four answers down before you take a call with a developer. A supplier who hears them and says an app is the wrong purchase for you is the supplier worth remembering for the job that is right.

The four kinds of build

Build	What it is	Suits	What it costs to keep
App builder on your store platform	A templated app that reads your existing catalogue, configured rather than coded	Testing whether an app earns anything, at the lowest risk	A monthly fee, and you live inside the template's limits
Cross platform custom build	One codebase producing both an iOS and an Android app	A real product with custom flows, on a sensible budget	Framework upgrades, plus two store review processes
Native per platform	Separate codebases, built with each platform's own tools	Heavy use of device features, or performance that has to be perfect	Two teams, two release cycles. The most expensive option to run
Progressive web app	Your website, installable to the home screen, no app store	Stores wanting app behaviour without the install barrier	Least to maintain, and some device features stay out of reach

One consequence worth knowing before you choose: an app has no organic search surface. Pages on your site can be found by anybody searching; screens in an app cannot. Store listings are discovered through app store search, which is a separate discipline with its own specialists, and the people who do that work are a different supplier from the people who build it. The progressive web app is the only option on that table that keeps the web surface and adds app behaviour, which is why it deserves more consideration than it usually gets.

What drives the price

• The number of custom screens, which is the honest unit of work. Count them in the brief and the quotes become comparable.
• Integrations. Payments, stock, delivery, loyalty, your email platform, your support desk. Each one is a contract with somebody else's system and each one can fail on its own schedule.
• Login and accounts, especially if customer records already exist on the site and have to match.
• Push notifications done properly, meaning permission, segmentation and a limit on how often you use them. Badly done push is the fastest route to an uninstall.
• Design, and the fact there are two design languages. iOS and Android expect different behaviour for the same actions.
• Store submission, which is a process with review cycles and rejections rather than an upload. Ask who owns it and what happens when a release is refused.

And the line most first budgets omit: maintenance. Operating systems update annually, frameworks and software kits move, payment libraries expire, and a store app that is not touched for eighteen months may simply stop building. Agree a monthly retainer or a yearly allowance in advance, or you will be negotiating it from a weak position in the middle of an outage.

The twelve things to have in writing

• The repository, with your organisation owning it from the first commit rather than being handed a copy at the end.
• Your own Apple and Google developer accounts, in the company's name, paid on the company's card. Apps published under an agency's account are the single most expensive mistake in this category.
• Signing keys and certificates, held by you, with the recovery process written down.
• Design source files, not exports.
• Every third party key and account in your name, with a list of what each one costs.
• A named maintenance arrangement with hours, response times and what counts as a fault against a change.
• The release process, who submits, who can approve a release, and what happens on a rejection.
• Where customer data lives, which jurisdictions, and who has access.
• Analytics and consent, including what is collected before a user agrees to anything.
• Acceptance criteria per screen, so done is a test rather than an opinion.
• A documented handover, including a written walkthrough of how to build and deploy, tested by somebody other than the author.
• What happens if you part company, settled while everybody is cheerful.

That list is the same discipline that decides whether any build stays yours, and the fuller version of the argument, including why the handover matters more than the design, is in the handover that decides a build.

Judging the companies

• Ask for two apps you can download now, and use them. Screenshots in a deck tell you about the designer rather than the build.
• Ask what they still maintain. A shop that only builds is a shop whose work you will inherit.
• Ask who writes the code, by name, and how much of their week is on your project. The answer to this question separates most shortlists.
• Ask about a release that was rejected and what they did. Everybody has had one; the useful signal is whether they talk about it plainly.
• Ask what they would not build for a store your size. A supplier with no opinion about scope is a supplier who will build whatever is in the brief, including the parts that will not pay.
• Get the same brief quoted twice, in screens rather than in weeks, and compare line by line.

If your store runs on a hosted platform, the shortlist should include specialists in that platform rather than general app shops, because the catalogue, checkout and customer records are already there. What those engagements contain is set out for two of the common platforms in hiring a Shopify development agency and the Magento diligence checklist.

After launch, the part that decides the outcome

An app with no installs is a cost. Plan the first three months before the build finishes: where you will ask for the install, what the customer gets for installing, the one notification you will send in week one, and the number you will judge it on. The sensible numbers are installs from your own customer base, the share of installers who place an order within thirty days, and repeat order rate for installers against everybody else. Getting found in the store itself is a separate job again, and the suppliers who do it are compared in how to build a shortlist of app marketing agencies.

Questions store owners ask

Does my store need a mobile app?

Only if customers buy often enough to open it, or if there is something the app does that the site cannot. For most stores the better spend is on the mobile site, the checkout and the email programme.

What is the difference between an app and a progressive web app?

A progressive web app is your website, installable to the home screen, with no app store involved. It keeps your search presence and avoids the install barrier, and it gives up some access to device features.

How long does a build take?

A templated builder app is days. A cross platform custom build with integrations is a matter of months rather than weeks, and store review adds time at the end that is outside anybody's control.

Who should own the developer accounts?

You, in the company's name, always. An app published under a supplier's account can be difficult to move and in the worst case has to be rebuilt and relaunched, losing the installs.

Can I reuse the app I already have on a new platform?

Usually not directly, though the design, the flows and the content survive. Treat the second platform as a build with a head start rather than a port.

What ongoing cost should I expect?

Store developer fees, any templated app subscription, the third party services, and a maintenance arrangement for operating system and library updates. Ask for that figure in the quote rather than discovering it in month fourteen.

The storefront you did not commission

An app is a surface you control completely and that only your installed customers see. There is now a surface you control not at all and that everybody sees: a buyer asks ChatGPT, Gemini, Perplexity or Claude where to buy something or which supplier to use, and the answer names two or three companies with a line of description each, assembled from what has been published about them. It reaches people who have never installed anything, and it is written from your web presence rather than your app. Worth reading before any budget is committed to a second storefront. AI Knows Us asks those buying questions across the main assistants and records which companies get named and what the answers were built from.