What custom e-commerce app development costs
By Abdalla Kamesh · Published September 27, 2026 · 5 min read
Quotes for custom e-commerce apps range from five figures to seven, which tells you the question is under-specified rather than that someone is lying. What varies is scope, and scope in mobile is not obvious from the outside.
Here is what the work actually consists of, so you can read a quote and know what is in it — and so you can tell whether you need one.
The work items
Discovery and design. Information architecture, wireframes, then visual design for every screen, in two platform idioms if you are doing it properly. A shopping app is not five screens: home, category, search, filters, product, variation selection, cart, address, shipping, payment, confirmation, order list, order detail, account, wishlist, notifications, empty states for all of it, error states for all of it. Thirty-plus screens before you have designed anything unusual.
The backend integration. Your app needs an API. WooCommerce provides one, so this is integration rather than invention — but it is real work: authentication, pagination, caching, offline behavior, error handling, and a sync strategy for prices and stock. Whoever builds it also has to decide what happens when your store is slow, which is the difference between an app that degrades and one that hangs.
The apps themselves. Either two native codebases (Swift and Kotlin) or one cross-platform codebase (Flutter or React Native). Cross-platform is usually the right call for a catalog app and is what most builders in this market use — the storefront in a StoreToNative app is Flutter, for the same reason.
Payments. This is where custom quotes diverge most. Handing off to your store’s own checkout is a day. Building a native payment flow means gateway integration, 3-D Secure, strong customer authentication, error and retry handling, and a PCI conversation. Why almost nobody does the second one.
Push notification infrastructure. Device token management, delivery, deep links, segmentation, and a way for you to send a campaign without a developer. That last part is a small internal product of its own.
QA. A device matrix, not one phone. Old Android hardware, small screens, large screens, slow networks, and every payment path.
Store submission. Two listings, two privacy questionnaires, screenshots at multiple sizes, certificates and provisioning. Usually quoted as a line item and usually underestimated.
Analytics. Installs, funnels, revenue attribution. Otherwise you cannot tell whether any of it worked.
The maintenance nobody budgets
This is the part that makes custom expensive over five years rather than one.
Annual OS releases. iOS and Android each ship a major version every year, and each one deprecates something. An app that is not touched for two cycles starts breaking in ways your customers report as “the app is broken.”
SDK and dependency churn. Every library you depend on has its own release cadence and its own breaking changes.
Store policy changes. New privacy requirements, new declaration forms, new technical requirements for uploads. These are not optional and they arrive on the platforms’ schedule.
WooCommerce and plugin updates. Your store keeps evolving. The app’s assumptions about your data have to keep up.
Your own changes. New categories, a redesign, a campaign, a new shipping rule.
A common rule of thumb in software is annual maintenance at some meaningful fraction of the original build cost. Whatever fraction you use, the important thing is that the number is recurring and non-optional, and that a fixed-price build quote with no maintenance line is an incomplete quote.
The one line item to interrogate
Ask any agency this: “which visual and merchandising changes will I be able to make myself, without you and without a store review?”
If the answer is “none,” then your marketing calendar now runs through a developer’s backlog and Apple’s review queue. Every banner is a ticket. Every seasonal theme is a release.
This is the single biggest structural difference between a custom app and a configuration-driven one. In StoreToNative, theme, colours, home layout, banners, intro slides and feature toggles are over-the-air configuration — published from a console, no rebuild, no review. In a custom app, someone has to build that capability, or you do not have it.
Budget for it explicitly, or accept the backlog.
When custom is genuinely right
Three situations, and they are real:
1. Your product is not a catalog. A configurator, a rental calendar with availability logic, a B2B pricing engine with customer-specific price lists, a made-to-measure flow. If the buying experience is the unusual part of your business, no catalog builder models it.
2. You have a genuine scale or integration requirement. An ERP that is the source of truth, warehouse logic, a loyalty programme that has to be first-class, multi-store or multi-currency complexity beyond what plugins handle.
3. The app is a product. If the app is a strategic asset with its own roadmap and someone’s job attached to it, you want to own the codebase.
If none of those describe you, custom is an expensive answer to “I want my catalog on a phone.”
The comparison to run
Take the agency quote and build a five-year table:
| Custom | Builder subscription | |
|---|---|---|
| Year 1 | Build cost | 12 × monthly + $124 platform fees |
| Years 2–5 | Annual maintenance × 4 | 12 × monthly × 4 + $99/yr |
| Design changes | Developer time + review each time | Included, over the air |
| Platform fees | $124 then $99/yr | Same |
| You own the code | Yes | No |
| Time to launch | Months | Days, plus account timelines |
Then ask the honest question: what do you get from owning the code that you cannot get from configuring a product? Sometimes the answer is “the thing my business is built on,” and custom is correct. Often the answer is “nothing I can name,” and the subscription is a better use of the money — with the difference spent on inventory, photography or ads.
A middle path worth knowing
You do not have to choose once and forever. Start with a builder, run the app for a year, and find out empirically what your customers use and what your store actually needs. If you discover a genuine requirement that no product supports, you will then be commissioning a custom app with a year of real data about what to build — which is a far better brief than the one you would write today, and a far cheaper way to discover it.
Related reading