Retail app development: two faces, one product
A shopper app and a merchant dashboard as one product. Physical-world offers, found nearby and redeemed in the store — not a cart, not IAP.

Retail app development, here, is not a branded cart. It is a shopper face and a merchant face on the same offers. The offer is consumed in the physical world.
T-CODE is the coupon example: nearby offers, discovered and redeemed in one app. Qassah is the salon-booking example: find a nearby shop, book a cut, collect visits. Both are physical-world services in Saudi Arabia. We do not invent a GMV. We do not hang a stack on the name.
The shopper face is a map, not a catalogue
Shoppers browse nearby stores and offers on a live map. They search by city or category. They save coupons and track status and value. They open a store’s location and reach out. They can browse as a guest, and create an account when ready.
That is not a product grid with checkout. Guest browse is a product decision. The map is the product. If the first screen is a catalogue, you are building a different app.
The merchant dashboard is the other face
Merchants set up a store profile. They add branches, and show or hide each one. They create time-limited offers, or offers capped by a number of codes. They set price, duration, and branch, then track status. They use redemption codes to confirm an offer was used. They track views, followers, used codes, and conversion rate.
This is a merchant dashboard, not a CMS. We will not re-teach what an admin is. The jobs above are the product.
One product, two faces
The same offer row. The merchant publishes it. The shopper sees it on the map. There is no sync job. Many merchants in one product is tenancy. Two clients on one project is the backend note. This section is the join. Not a third architecture essay.
Physical-world offers are not in-app purchase
If the app collects money for goods or services consumed outside the app, Apple requires methods other than In-App Purchase — Apple Pay, or card entry. Guideline 3.1.3(e). IAP is for virtual goods. Digital coupons redeemable for digital goods are IAP. A coupon redeemed in a store is the first category, not the second.
Play Billing is only for digital items. Physical goods and physical services are out of it. The class of product is a local deal, redeemed in the world. We do not say T-CODE charges in-app. We do not say it uses Apple Pay. The work page is silent on payments. The rule is still the rule. The two store checklists are their own note.
What this is not
- A Shopify app.
- A Groupon clone with an invented market size.
- An IAP coupon wallet.
- AR try-on, voice checkout, blockchain.
Those are other products. If the pitch is only shopper screens, the product is not scoped.
What to scope first
First: map or city and category browse. A guest path. A merchant profile. One offer type — time, or a cap. Redemption. The four merchant numbers. Later: paid acquisition, fancy charts, a second marketplace. If money will move in the app for in-store offers, the payment path is a v1 decision, not a store-listing surprise.
Read T-CODE as a product. We do not invent a stack or a GMV for it. Write to us with both faces in the room. Not only the map.
Tell us what you’re building.
Write to us with the product you want built. You will get a considered reply from the people who would do the work.
Start a conversation