B2C loyalty app: how to grow repeat purchase without burning margin

The most common loyalty-program mistake is optimizing for gross sales. A program can increase revenue while destroying margin by discounting customers who would have purchased again anyway. Start with one model: CAC, contribution margin, purchase frequency, AOV, discount cost, reward cost, returns, support, points liability and app maintenance cost.

Only then does repeat purchase rate mean anything. If the second purchase grows while discount share and returns grow as well, the outcome may be worse than before. If purchase frequency grows in groups without heavy discounting, the app starts to work like an owned commerce channel, not just a promotion machine.

In commerce projects we use this logic during DDT. We define what success means before building: time to second order, share of repeat orders, incremental push lift, margin after discount, D30/D90 retention, opt-in quality and the operating cost of points balances. Without that definition, the technology may look good while the board still cannot tell whether the program earns money.

A loyalty app works best where the customer has a natural reason to return: supplements, cosmetics, fashion with frequent collections, products for children, food, sport, consumables and omnichannel retail. In these categories the app can shorten the path to the next order: it saves preferences, shows availability, reminds about replenishment, simplifies reorder and provides value that does not always have to be a discount.

The app starts to hurt when the brand rewards every purchase equally, sends mass promotions to everyone and has no control groups. Research on channel adoption shows that the acquisition path matters: promotion-driven adopters may behave differently after adopting a channel, including forward buying or lower later profitability.

The practical test is deliberately harsh: if you turn off the discount, does the customer still have a reason to use the app? If the answer is no, you do not have loyalty. You have coupon distribution. A strong app adds convenience, status, service, personalization and predictability, while discount is one tool, not the whole product.

A plastic card, phone number at checkout or POS customer identifier may still be necessary. Not every customer installs an app, not every customer stays logged in and not every purchase starts on mobile. A loyalty project should not begin with "app or card?". It should begin with "how will we recognize the same customer in every channel?".

The app wins when you need more than points accrual: benefit wallet, status, in-store scanner, order status, opt-in push, shopping lists, saved preferences, returns, store pickup, community, gamification or personalized reorder. A card is an identifier. An app can be the interface of the relationship.

For omnichannel brands, the safest model is hybrid. POS and e-commerce must recognize the customer even without the app, while the app gets the functions that a card cannot carry: context, notifications, history, service and personalization. Then the app does not cannibalize the program; it makes the program more useful.

Push has no CPC, but it is not free. The cost is consent, attention, opt-out, app uninstall and brand trust. A loyalty app needs frequency caps, segmentation, quiet hours, a preference center and holdout groups that do not receive a message.

A good notification responds to the customer moment, not the marketing calendar. Examples: "the product you buy every 45 days is available for pickup today", "premium status expires in 7 days", "your favorite category has new arrivals", "return accepted, funds are available in wallet". That is service plus commerce, not discount spam.

That is why open rate is not enough in a loyalty dashboard. You need incremental conversion versus holdout, revenue per recipient, margin after reward, unsubscribe rate, opt-out rate, uninstall rate and the long-term change in purchase frequency. Only then can you say whether push replaces part of paid remarketing or merely shifts orders forward.

Many retailers start with elaborate status mechanics, while the biggest lift is often simpler: the customer needs to buy again something they actually consume or return to a category they buy cyclically. That is why buy-again and replenishment flows matter so much in commerce apps.

Research on Buy It Again recommendations shows that category-frequency prediction can improve recommendation quality at very large scale. In practice, the app does not need to guess "what is trendy"; it should understand the customer purchase rhythm, category seasonality and likely return moment.

This is also safer for margin. Instead of giving everyone 15% off, the app can remind, bundle, add service value, simplify pickup or offer a benefit only when the model shows risk of losing the customer. Personalization should increase relevance, not the number of coupons.

Technically, the most important part of a loyalty app is often not in the app. It is in the backend: one customer profile, points ledger, accrual rules, coupons, wallet, marketing consent, purchase events, POS/ERP/PIM/WMS integrations, returns, corrections and reconciliation after failure.

A points balance should not be an overwritten number. It should be derived from transactions: purchase, return, bonus, expiry, correction and benefit redemption. This makes the system auditable, reduces abuse and lets support explain where a balance came from. PostgreSQL works well as the system of record, Redis can speed reads, and queues help process POS and e-commerce events without blocking checkout.

At GMI we usually design this backend in NestJS because TypeScript, domain modules, validation, testing and integrations fit commerce teams well. If the commerce core is headless, Medusa can own part of the buying domain, while loyalty becomes a separate module or service with a clear API. That reduces vendor lock-in and lets the program evolve without rewriting the whole store.

A loyalty app is rarely a one-off project. After launch, new campaigns, benefits, segmentation rules, integrations, App Store and Google Play changes, analytics, crash monitoring and UX updates keep arriving. The stack should reduce maintenance cost, not only first-release cost.

React Native lets teams build one codebase for iOS and Android while still using native platform APIs. Expo and EAS help with builds, updates, submissions and release-process observability. In a loyalty project that matters because marketing and e-commerce teams need fast iteration without two separate native roadmaps.

That does not mean Swift and Kotlin are wrong. If the app has very heavy native requirements, separate native apps may be justified. For most B2C loyalty apps, the bigger value is a shared codebase, fast experiments, consistent UX and lower cost of ongoing development.

A loyalty dashboard should connect marketing, e-commerce, finance and technology. The minimum set is active members, push opt-in, repeat purchase rate, time to second purchase, purchase frequency, AOV, app share of orders, redemption rate, points liability, margin after discount, returns rate and crash-free sessions.

The second layer is causal measurement. Holdout groups for push, promotions and benefits show what the program actually changes. Cohorts show whether new program members return better after 30, 60 and 90 days. Segments show whether the benefit works on high-margin customers or mostly bargain hunters.

The third layer is operations. Does POS synchronize events fast enough for the customer? Do returns correct points? Can support see balance history? Does the dashboard distinguish revenue, gross margin and contribution margin? Without those answers, the app may have nice MAU, but it will not manage profitability.

A realistic B2C loyalty app MVP usually fits in PLN 80,000-120,000 when scope includes login, profile, card/wallet, balance, basic benefits, push, analytics, an operations panel and one main integration. A fuller ecosystem with POS, ERP, e-commerce, points ledger, segmentation, dashboard and campaign automation more often starts from PLN 160,000-240,000.

The biggest cost differences do not come from screens. They come from integrations and data quality. A single online store is priced differently from omnichannel with in-store tills, returns, contract discounts and migration from an old program. That is why fixed price should come after DDT, when systems of record and risks are known.

At GMI we work outcome-first: discovery and risk map, then scope, fixed price and code ownership after paid milestones. That matters in loyalty because ready-made SaaS can be fast at the start, but expensive or limiting when the brand wants its own ledger, POS/ERP integrations and full roadmap control.

The SFD app, built by GMI Software, passed 100,000 downloads, holds a 4.9 App Store rating and was nominated for Mobile Trends Awards 2025 in the Commerce category. It is proof that mobile commerce can become a real relationship channel, not only an add-on to a store.

The main lesson is not "copy SFD features". Categories, margins, purchase frequency and communication rhythm differ by brand. What is worth copying is the operating model: the app as an ongoing product, integrations as foundation, purchase UX as part of loyalty and measurement as the condition for further investment.

If a B2C brand wants a similar effect, it should start with its own customer-return map: when the customer naturally returns, what blocks them, which benefits do not destroy margin, where POS loses identity, where e-commerce creates friction and which experiments must run in the first 90 days after launch.