Most Shopify brands under $2M should stay on an app builder like Tapcart at $250 to $1,000 a month. A custom Flutter build becomes the better answer only once builder constraints, rather than builder cost, start capping what you can merchandise and ship.
A framework has never fixed a conversion rate. It only changes how quickly you can fix one yourself.
Shopify merchants moved $14.6 billion over Black Friday Cyber Monday weekend in 2025, on an average cart of $114.70. Almost none of that ran through a custom-built mobile app. It ran through mobile web, and through the two to three figure monthly app builders that most direct-to-consumer brands install and forget about.
That matters, because the pitch for building your own app is getting louder, and the framework doing most of the talking is Flutter. The argument in its favour is real: one codebase, two app stores, and a design system you control rather than rent. The argument against it is also real, and it is the one the pitch decks leave out. Every merchant I watched stall out between $500K and $2M during my years at Shopify stalled for the same reason, and it was almost never a missing capability. It was premature complexity. Too many apps, too many channels, too many builds running before the fundamentals were solid.
So this piece is not about whether Flutter is good technology. It is. The useful question for an operator is narrower: at what point does owning a mobile codebase produce more revenue than renting one, and what does it cost you to be wrong about the timing?
A mobile app changes retention economics, not acquisition economics, and that distinction decides whether the whole project is worth running. App installs come almost entirely from people who already bought from you. The app does not win you new customers; it gives you a direct channel to the ones you have, with saved payment credentials, a home screen icon, and push notifications that bypass the inbox entirely.
This is why the conversion numbers look so dramatic and why you should discount them hard. App builders publish figures showing their apps converting two to three times better than mobile web, and those figures are usually accurate and almost always misleading. The app audience is self-selected repeat buyers. Compare a channel made of your best customers against a channel made of everyone and the app wins by construction. When Nosto and Tapcart announced their integration, the headline figure was a brand reporting its app converting far better than its mobile site. Treat those as vendor-reported marketing claims rather than benchmarks, and go read how those integration claims are framed before you quote one back to your board.
The honest version of the app case is this. If 30% or more of your revenue already comes from repeat customers, an app concentrates that revenue in a channel with near zero marginal delivery cost. Push notifications replace paid retargeting for your existing base. If your repeat rate sits under 20%, an app is a well-designed container for traffic you do not have, and no framework choice fixes that.
An app builder is the correct default for almost every Shopify brand under $20M, because it converts a capital project into a cancellable subscription. The Tapcart listing on the Shopify App Store shows base tiers at $250, $500, and $1,000 per month, each with additional charges tied to in-app performance. Shopney, Vajro, and Plobal Apps occupy the same lane at varying price points, some of them on revenue-share models rather than flat fees.
Add the fixed costs nobody quotes you. An Apple Developer account runs $99 a year and a Google Play Developer account is a one-time $25. Call it $124 in year one regardless of which platform you pick. A brand on the $500 tier is therefore looking at roughly $6,100 in year one, all in, for a native iOS and Android app that a marketing coordinator can update without opening a ticket.
That last part is the real product. You are not buying an app. You are buying the removal of an engineering dependency from your merchandising calendar. When Eric Netsch came on the podcast to talk through how mobile shopping behaviour differs from mobile web, the operational point that stuck with me was not the conversion lift. It was that brands shipping app changes without a developer in the loop ship more of them.
The builders have a genuine structural weakness, and it is worth naming now because it becomes the trigger later. Most of them run a separate design surface from your Shopify theme, which means every sale banner, navigation change, and seasonal refresh gets built twice. At two updates a week that is an annoyance. At twenty it is a headcount.
You have outgrown an app builder when it starts blocking revenue you can name, not when the invoice starts feeling large. Cost alone is a bad trigger, because a custom build is more expensive in every year, not fewer. Three signals actually matter, and you want at least two of them firing before you take a quote seriously.
The first is a merchandising capability the builder cannot deliver. Not a nice-to-have, a named one. A bundle configurator your category needs, a made-to-order flow, a subscription management screen your Recharge customers keep calling support about. If your merchandising team has a list of three things they cannot do and each one maps to revenue, that is a real signal.
The second is duplicated maintenance at a volume that shows up in payroll. Track it for one month: hours spent rebuilding in the app what already exists on the storefront. If that lands above 20 hours a month, you are already paying for a build, just in salary rather than invoices, and with none of the asset at the end.
The third is performance-based pricing crossing the line where a fixed engineering cost is cheaper. The tiers with in-app performance charges scale with your success, which is fair and also means the arithmetic eventually inverts. Model it at three times your current app revenue. If the subscription at that volume exceeds two engineers, the ownership conversation is legitimate.
None of these is a reason to rebuild your whole storefront. The same discipline that keeps a Shopify tech stack to the apps that earn their place applies here. The question is always whether the constraint is costing you more than the replacement will.
Flutter’s advantage over separate iOS and Android builds is coordination, and in retail that translates directly into release cadence. One team, one backlog, one set of designs, and features that land on both platforms in the same week rather than the same quarter. For a business running promotions, loyalty changes, and payment additions on a weekly rhythm, that is the whole argument.
The published retail results support it, with one caveat you should hold onto: all three of the cases below sit on Google’s own Flutter showcase, which means they are the best available outcomes selected by the framework’s owner. Read them as a ceiling, not an average.
Whirlpool’s Brazilian appliance marketplace Compra Certa shipped its first version in 30 days on a 92% shared codebase, reporting a 50% reduction in development cost and a 35% increase in development speed. eBay Motors went further, reaching 98.3% code sharing and weekly releases to both app stores, with features like live chat and escrow arriving on iOS and Android simultaneously. The team’s own engineers wrote up what changed in their working process after the switch, and the honest summary is that one source of truth meant one set of meetings.
The case closest to a DTC operator’s situation is Grupo Soma. Its in-house team rebuilt the Farm app for Android and iOS simultaneously while implementing a new design system, then discovered mid-project that the result could be white-labelled across the group’s other brands. If you operate a portfolio, that is the leverage: the second brand’s app costs a fraction of the first.
A Flutter app replaces your customer-facing mobile layer and nothing else, which is the single most important thing for a Shopify merchant to understand before signing anything. Inventory stays in Shopify. Checkout stays in Shopify. Klaviyo keeps sending, Recharge keeps billing, Gorgias keeps handling tickets. The app talks to all of it through the Storefront API, the same way any custom front end does.
This is architecturally identical to the decision you may already have made about your website. If you have worked through how headless commerce separates the storefront from Shopify’s back end, you already understand the trade: more control over the experience, more dependence on the team maintaining it. A custom mobile app is headless with a smaller surface area and an app store review queue attached.
The practical consequence is that you do not need to replatform to explore this. A brand on Shopify Plus with a Tapcart app today can build a Flutter app against the same catalogue, run it as a beta to a segment of its list, and keep the builder running until the replacement earns the switch. That parallel period is expensive and it is also the only responsible way to do it.
Where teams get hurt is assuming the app inherits the storefront’s behaviour. It does not. Discount logic, gift card handling, tax display, and subscription upsells all have to be implemented deliberately against the API. Budget a discovery phase of four to six weeks before anyone writes production code, purely to map what your storefront currently does that nobody documented.
Flutter changes how fast you can ship, and nothing about whether what you ship works. This is the part the framework conversation consistently skips, and it is where most custom app projects actually fail.
It does not solve distribution. A new app starts at zero installs and every one of them has to be earned from your existing email list, your packaging inserts, and your site banners. Budget a full quarter of promotion to get meaningful install volume, and expect the first cohort to be your most loyal customers, which will make your early metrics look better than the steady state.
It does not solve app store operations. Review submissions, rejections, version rollbacks, and the two-week lag between deciding something and customers seeing it are structural to native apps regardless of framework. Builders absorb this work for you. Owning the codebase means owning the queue.
It does not solve hiring. Dart is a smaller talent pool than JavaScript, which matters when your one Flutter developer leaves. This is the strongest argument for React Native and you should weigh it honestly rather than letting a vendor wave it away. If you are going to depend on an agency rather than hire, the selection process is the project. A credible Flutter app development company should be able to show you shipped commerce apps, not just shipped apps, and our guide to what Shopify development work costs and how to vet the team doing it covers the questions that separate a partner from a vendor.
And it does not solve retention. An app that pushes three notifications a week to a customer who buys twice a year gets deleted. The framework is indifferent to that. You are not.
The right mobile decision is almost entirely determined by your stage and your repeat rate, and almost not at all by which framework is currently winning the developer surveys. Hold your own numbers against this.
Two notes on reading that table. The revenue bands are a proxy for organisational capacity, not a rule. A $8M brand with two in-house engineers and a portfolio of three labels has a stronger case than a $30M single-brand business with no technical staff, because the portfolio makes the second app nearly free and the staffing makes the first one maintainable.
The second note is the one I would want a founder to actually keep. If you are choosing between a custom app and a merchandising hire, a better returns calculation almost always favours the hire. The app builder exists precisely so that the mobile channel does not have to compete with people for budget. Build the app when the constraint is genuinely the software, and not before.
A custom commerce app is a six figure project in most cases, and agencies publishing rates in this category commonly quote ranges from roughly $50,000 to $200,000 for the initial build. Treat those as illustrative rather than verified, because scope drives the number far more than the framework does. The figure that surprises merchants is not the build, it is year two: ongoing maintenance, app store submissions, OS version support, and feature work typically run 20% to 30% of the original build cost annually. Compare that total against a $250 to $1,000 monthly builder subscription before you decide the subscription is expensive.
Neither is better in general, and the deciding factor for most merchants is hiring rather than technology. Flutter uses Dart and ships its own rendering engine, which gives you tighter control over how the interface looks and behaves identically across iOS and Android. React Native uses JavaScript, which means a far larger pool of developers who can maintain it and lower risk if your one mobile engineer leaves. If you have an existing JavaScript team or plan to hire from a broad market, React Native reduces key-person risk. If you are working with an agency that specialises in Flutter and your priority is a heavily branded, animation-rich interface, Flutter is the stronger fit.
Yes, through the Shopify Storefront API, and your back end does not change. Products, inventory, customer accounts, and cart all sync from the same Shopify catalogue your website uses, and checkout can hand off to Shopify’s hosted checkout so you keep Shop Pay and your existing payment configuration. Your Klaviyo flows, Recharge subscriptions, and Gorgias support workflows continue operating on the same data. What does not carry over automatically is storefront logic: discount stacking rules, gift card behaviour, and upsell placements all have to be rebuilt deliberately against the API, which is why a discovery phase of four to six weeks is worth budgeting.
Move when the builder blocks named revenue, not when the invoice feels large. Three signals justify the conversation, and you want at least two firing. First, your merchandising team has specific features the platform cannot deliver and each maps to real revenue. Second, duplicated maintenance between your Shopify theme and your app design surface exceeds roughly 20 hours a month. Third, performance-based pricing modelled at three times your current app revenue costs more than two engineers. If your only complaint is the monthly cost, stay. A custom build is more expensive in every single year, not fewer.
App conversion rates do come in higher, but the comparison is not like for like and most published figures overstate the effect. App users are overwhelmingly existing customers who have already bought, already saved payment details, and already opted into notifications. Measuring that self-selected group against all mobile web traffic guarantees a flattering result. The useful test is incremental: does your app generate revenue you would not otherwise have captured, or does it move the same repeat purchases into a different channel? If your repeat purchase rate is under 20%, an app is unlikely to change your economics regardless of how it is built.
