A mobile app for an online store is a separate business

The store icon on a phone screen looks like just another view of the same store. Meanwhile, an online store’s mobile app functions as a separate business in the books: it has its own revenue, its own costs, and someone who reports on its performance every month. The store thrives on people finding you. The app thrives on people coming back to you - and that’s a completely different revenue model. Before you sign off on the quote, factor in that second business.

An app is not just a prettier version of a website

A mobile app is another product within the company, with its own profit and loss statement. It thrives on the fact that someone has a reason to tap the icon and see what’s new, even when they don’t have a specific need to make a purchase. On the other hand, someone manages it every day and plans the season within it. Those who order it as a better mobile version of their store are buying a product they don’t intend to manage and spending money they won’t get back.

The most costly mistake isn’t in the implementation price. It’s in the budget line item from which that price is drawn. An ecommerce mobile app usually ends up in the “UX improvements” category, alongside a shopping cart redesign and new photos on the homepage. Cosmetic changes are judged by appearance, so no one later comes back to ask whether the app made money. After a year, you have a product that generates monthly maintenance costs, and no data to tell you whether it’s worth keeping.

The market has already weathered one such wave. A few years ago, the industry was debating whether Progressive Web Apps (PWAs) would replace native apps. They didn’t; both forms remain, each with its own use cases, and the choice between them is a separate topic for a separate article. Before considering the technology, you need to ask yourself something else: Will my product and business model work well as an app? Where will such an app generate additional revenue, and will it cannibalize the store in the process?

How does the app make money in the first place: the economics of retention

Repetition has a name in this context: retention. And that’s what keeps the app going. No one installs an app for a store they don’t know. The icon on a phone’s screen is the result of previous purchases and experiences with your brand; hardly anyone installs an app just to make their first purchase or simply browse products. So when you evaluate the app as just another sales funnel, the numbers don’t add up, because you’re measuring it against a goal it wasn’t designed to serve.

This is best illustrated by customer lifetime value. Those who engage with the brand across multiple channels simultaneously (website, email, text message, brick-and-mortar store, app) are clearly worth more to the company than single-channel customers, with the difference reaching nearly one-third. The app contributes to revenue here as part of the overall portfolio, along with the other touchpoints, so asking about its standalone contribution to revenue usually leads to a false conclusion.

A store that, after a year, focuses exclusively on sales from the app is likely to disable the channel that was actually boosting its performance elsewhere.

The mechanism itself is straightforward. Personalized offers, promotions, and content go where the customer has already agreed to receive them, so subsequent purchases happen more frequently and more quickly. Underlying this is a simple calculation that the industry has known for years: acquiring a new customer can cost several times - and in extreme cases, more than twenty times - as much as the maintenance costs for one who has already made a purchase.

What has changed, however, is customer demand. Today, 69% of Poles consider loyalty programs an effective way to reward customers, and 59% expect every brand to have its own program. This is according to a study by Mando Connect and YouGov “Understanding Loyalty in Europe 3.0” from 2025. This second expectation has grown by 9 percentage points year-over-year - faster than anything that can be said about interest in the apps themselves. People aren’t demanding an app. They’re demanding to be recognized and rewarded for coming back.

The order in a typical brief is therefore reversed. First, a decision is made about what the program should be: what the customer gets, for what, how often, and why it should matter to them. An app is often the best medium for such a program because it provides notifications, a membership card, and purchase history all in one place. It is not a loyalty program in and of itself and cannot make up for the lack of one.

Without a USP, there is no project

An app that does exactly the same thing as a website competes with the company’s own online store for the same users, and the money spent on it usually never pays off. It really only makes sense in one scenario: as a first phase, a foundation for something that is yet to be built - and only if someone has actually planned that second phase.

We believe that software should pay for itself, and we stand behind what we build. That’s why, when asked about an app, we delve deeper into the topic instead of simply jumping into development. When someone comes to us with a decision already made, the first question we ask is: what does this app offer the customer that a store does not?

A competitive advantage doesn’t have to be elaborate - and therefore often costly to implement. For a store with a solid multistore engine, the simplest approach is to set aside a portion of the product lineup: limited-edition products available exclusively in the app, or promotions you won’t see on the website. The customer gets a reason to keep the app icon on their screen, and you get a channel that pays for itself through user engagement. It’s a business decision that doesn’t require any exotic technology.

The question of whether it’s worth developing a mobile app for a store is therefore decided long before any quote is provided. This advantage is developed by marketing and sales, not the implementation team; we sit down with the client for workshops because from the other side of the table, you can see things that no one internally notices anymore. Usually, a single workshop session and the subsequent data analysis are enough to answer this question - or at least to lay the foundation for the assumptions, which the marketing team will then refine. The code can always be written. The reason why someone will click that icon for the third time needs to be figured out beforehand.

Loyalty is not a discount auction

Tuesday, 10 a.m. A single limited-edition pair of shoes appears in the app, and a crowd of people has been waiting for that very minute - people whom no one had to entice with a price. Nike has built an entire ecosystem around this: drops, early access for members, and a rotating product catalog that no one on the outside will ever see. The number of members there runs into the hundreds of millions: in the 2021 results Nike reported over 300 million accounts, and member demand grew faster than total digital sales, reaching a record three billion dollars in a single quarter. None of these people were lured in by a coupon.

In practice, conversations about a loyalty program in an app almost always boil down to the discount rate. It’s the most expensive tool you can choose, because you pay for it through a margin on every single transaction, and the easiest to copy, because competitors will copy your “minus ten percent” offer within a week. What’s worse is what it does to the customer. Someone accustomed to coupons stops buying when they need something and starts waiting for the next one.

Mechanics that work without this are well-documented and boringly predictable: early access to collections, member-only events, invitations to co-create the product, paid VIP programs with a tangible benefits package, and value programs where a portion of the purchase goes toward a cause chosen by the customer. They all have one thing in common. In these programs, the customer gains the status of an “insider,” and that keeps them engaged more effectively than a lower price. A curated selection - which is where most stores start - is the simplest entry point into this logic, but it’s usually not the limit of it.

Discounts aren’t off-limits. They just need to be used rationally and wisely, tied to a well-thought-out strategy, rather than handed out in isolation from it. This is clearly illustrated by cashback, which, instead of reducing the bill today, is credited to the customer’s loyalty card and remains there for the next purchase; Modivo, for example, operates this way. The customer has a reason to return, and the store records the transaction at the regular price.

When designing an app, the interface usually gets the most attention, but it’s actually the mechanics that should be the focus. Any competent agency can deliver screens, animations, and biometric login. No one will come up with the program’s principles - that is, what the client gets, for what, and at whose expense - for you. And once they’re up and running, someone has to maintain, account for, and improve them every month.

The ceiling of possibilities: an app with its own team

IKEA has set the bar. In the IKEA Place app, you can place a sofa in your own living room before you buy it: 3D models of over three thousand products you can try them out at actual scale using your phone’s camera. This single feature answers the question that has always been central to online furniture sales: “How will it look in my home?” A website cannot handle this in the same way, because this feature relies on the phone’s camera and processing power, not on a browser.

However, you don’t have to aim for this level right away. When building an app for a store, start with three best practices that are technically inexpensive but effectively turn the app into a separate channel.

Multistore: You can enable and disable products on a per-channel basis

The foundation is the Multistore engine. Within it, the app is treated as a separate sales channel: it uses the same catalog and the same data as the store, but you can enable or disable each product in the app independently of the website. This is the entire technical foundation for the product range available only in the app; the rest is determined by a business decision regarding which products to include and for how long.

Separate promotions for the store and the app

We design promotional rules to be separate from the start. You set up a coupon, discount, or special promotion separately for each channel, so the app runs its own promotion without affecting prices on the website, and the store runs its own. Without this separation, every “app-only promotion” ends up requiring manual workarounds, and mechanics like cashback have nowhere to be implemented.

Marketing automation points, rewards as individual codes

The most cost-effective way to get started with a tangible loyalty program is to expand integration with marketing automation, which most stores already have anyway. This same integration begins collecting points and enforcing the program’s rules, while the initial redemption of points is handled through individually generated discount codes. Implementation requires minimal effort, and the customer sees a fully functional program from the very first month - not just a promise.

Every such thing has an owner. Someone designed it, someone built it, someone tests it on two systems with every release, and someone handles support tickets when it stops working on a new phone model. In a company like this, an ecommerce mobile app is a separate product with its own team and its own budget. So when a screenshot of someone else’s app is shown during a meeting and the question arises, “Why don’t we have something like that?”, the honest answer starts with the monthly maintenance cost.

The cost of app maintenance, which no one mentions in their offer

On June 28, 2025, an item was added to this bill that had not been included in any assessment the previous year. As of that date, the European Accessibility Act applies to mobile apps just as it does to online stores. Everything you’ve worked to bring into compliance on your website over the past few years must be done all over again, using different technology and following different rules. The app is responsible for its own compliance, and no one will verify it during a store audit.

Compliance is just one of the items that cannot be put off. The app lives in two app stores, and they dictate the pace: the operating system version changes, the publisher’s requirements change, and either you release an update, or your app quietly stops working for some customers. The option “we’re not updating this year” isn’t on the menu. The cost of app maintenance is therefore a subscription fee just to keep the product on the market, and you can’t suspend that subscription for a quarter when the budget gets tight.

Releases and compliance are still the easy part, because they stay on schedule. People are the harder part.

A well-designed app pulls data from the same CMS that powers the store, so content, prices, and product selection are managed by a single team. The backend is often shared as well. However, with a traditional online store, in about nine out of ten cases, a separate person or team is responsible for the app itself, because someone needs to be familiar with two mobile platforms, their release cycles, and publication procedures. This ultimately amounts to a full-time position or a permanent contract, since the current developers won’t be able to handle it on the side.

The last item is the least visible because it doesn’t appear in the app’s offering. The app drives traffic to the same infrastructure that hosts the store. Queries increase, integrations run more frequently, and after a few months, the cost of maintenance for the entire ecommerce platform goes up.

These items must be totaled and placed next to the value that the application is intended to deliver. Only such a document shows the balance sheet of the second business.

When Not to Build an App

Is it worth developing a mobile app for a store? Framed so broadly, this question has no clear answer, because two companies with similar revenue would receive opposite recommendations from us. It only makes sense when broken down into two entry conditions. Do you have a customer base to build loyalty among? And will the app do something your store can’t handle on its own?

When the answer to both is no, we tell the client straight up: don’t build an app. There’s nothing to argue about, because there’s nothing to launch. A program without returning customers becomes nothing more than a set of empty terms and conditions, and an app that duplicates the store’s functions simply takes the same people down the same route - only at a higher cost. That same budget would usually go further in the store itself and across the other channels through which the brand already reaches its customers.

The second condition, however, can work on its own. There are product lines where a smartphone offers something that a browser cannot provide in the same form: augmented reality, as in the IKEA example, addresses a concern that no photo or dimension chart can resolve. If your product category has such a concern, the app proves its worth even with a modest loyalty program.

So before you sign the quote, sit down with four questions. What exactly will the client get in the app that they won’t get on the website? Who, by name, will maintain it a year from now? From which budget line item will this cost be allocated, so it doesn’t get lost in the UX budget? And how will you know in twelve months that it has paid for itself? These four answers fit on a single page and save you from having to have conversations that you’d otherwise have to have after the fact.

A mobile app is not a mandatory feature for a store. It is a business venture that you either pursue or don’t, just like any other.

Summary

The most interesting thing about the decision regarding the app is that it doesn’t really have anything to do with technology at all. It’s a test to see if you can name a reason why a customer would come back to you. A store can survive for years on ad-driven traffic and never answer that question; an app can’t be fooled that way, because without a reason to return, it simply disappears from the phone. That’s why it’s worth doing this analysis even if you’re not planning to build an app. If a reason exists, the app will reinforce it. If it doesn’t exist, no technology can create it. So there’s one question to ask before getting a quote: what will your app give the customer that a store can’t?