How a discount marketplace works
If you want to know how to build an app like Wish, start with what makes this kind of marketplace different from a normal online shop. A regular store owns its inventory, buys goods, and sells them to you. A discount marketplace owns almost nothing. Instead it connects two groups: a large number of small sellers offering low-cost products, and buyers who enjoy hunting for a bargain. Your platform is the meeting place, the payment handler, and the trust layer between them. You are running a market, not a warehouse.
That distinction changes everything about the product. Because you have many sellers each listing many cheap items, your catalogue is huge, messy, and constantly changing. No shopper could ever browse all of it. So the app does not ask people to search a neat set of shelves. It shows them a feed of products it thinks they will like, learns from every tap, and keeps surfacing more. The magic of this kind of app is not the checkout, it is the discovery. People open it to see what cheap, surprising thing appears next, the same way they open a social feed to see what is there.
This is a two sided marketplace, and like any marketplace it only works when both sides are healthy at once. Too few sellers and the feed is thin and repetitive, so buyers get bored and leave. Too few buyers and sellers make no sales, so they stop listing and drift away. A discount marketplace succeeds when there are enough cheap, interesting products to fill an endless feed and enough buyers making purchases to keep sellers listing. Getting that balance going is the real founding challenge, and we return to it later. For a wider look at this pattern, our guide on how to build a marketplace app is a good companion to this one.
There is a helpful way to think about the two jobs inside this business, because they are not the same. One job is software: the buyer app, the seller tools, the discovery engine, the payment plumbing. The other job is operations and supply: recruiting sellers, getting enough cheap and varied products listed, and dealing with the reality that goods often ship a long way and sometimes disappoint. Good software makes the operations easier, but it does not remove them. Founders who do well treat the app as the tool that runs their marketplace, not as a machine that fills itself. Keeping that in mind stops you expecting the code to solve a supply problem that only outreach and merchandising can solve.
One more framing is worth having early. Wish style shopping is impulse shopping. People are not arriving with a specific product in mind and comparing three brands. They are browsing for fun, and buying because something cheap caught their eye. That means the whole app is designed around low prices, quick delight, and a low barrier to hitting buy. It also means expectations are set accordingly: a bargain that takes a while to arrive is acceptable in a way it would not be for a full price purchase. Understanding the psychology of the bargain hunter shapes every screen you build.
The buyer app: discovery over search
The buyer app is the part everyone pictures, and its defining trait is that discovery comes before search. Most shopping apps put a search bar front and centre and assume you know what you want. A discount marketplace does the opposite. It opens on a feed of products, tuned to you, and invites you to scroll. Search is there, but it is the secondary path, not the main event. Getting this ordering right is what makes the app feel like a bargain hunt rather than a catalogue.
The discovery feed
The home screen is a scrolling feed of product cards: a photo, a very low price, and little else. It is designed to be tapped and scrolled quickly, the way a social feed is. As the buyer taps into items, saves them, or buys, the feed reshuffles to show more of what they seem to like. This feed is the heart of the buyer experience, and it is why the recommendation engine, covered further down, matters so much. A feed that shows dull or irrelevant items loses people in seconds.
Product pages
Tap a card and you reach the product page: more photos, the price, shipping estimate, seller information, ratings and reviews, and variations like size or colour. Because trust is a live question with unknown sellers, reviews and photos from other buyers carry a lot of weight here. The product page has to give an impulse buyer enough confidence to tap buy on a cheap item without a long deliberation, while being honest about what they are getting and how long it will take to arrive.
Search and categories
Search still matters for the times a buyer wants something specific, and browsing by category helps people who arrive in a shopping mood without a target. Both feed into the same discovery loop, because a search or a category tap is another strong signal about what this person likes, which the feed then uses. So search is not separate from discovery, it is one more input to it.
Cart and checkout
The cart holds items, often from several different sellers at once, which is a quiet but important detail. Checkout has to be fast and low friction, because any hesitation kills an impulse purchase. It collects the address, takes payment once for the whole cart, and then splits that order behind the scenes into separate shipments from each seller. The buyer sees one simple purchase. The system deals with the complexity. Our guide on how to build an ecommerce app goes deeper on cart and checkout patterns.
Order tracking
After buying, the buyer wants to know where their order is, especially when shipping takes a while. Order tracking shows the status of each shipment in the order, since items from different sellers travel separately and arrive at different times. Clear, honest tracking is one of the main tools you have for keeping a buyer calm during a long wait, and it heads off a large share of support questions.
The seller side
For every buyer scrolling the feed, there is a seller who listed the item, priced it, and has to ship it. The seller side is less glamorous than the buyer app, but it is half the marketplace, and a discount platform lives or dies on having many sellers with plenty of cheap, varied stock. If the seller tools are painful, sellers list fewer items or leave, the feed goes stale, and buyers follow. So the seller experience deserves real care, not an afterthought.
Listing products
Sellers need a simple way to create listings: upload photos, write a title and description, set a price, and define variations like size and colour. Because many discount sellers list large numbers of items, the tools that make this fast matter, including bulk uploads and easy editing. The easier you make listing, the more stock fills your feed, so friction here has a direct cost to the whole marketplace.
Managing inventory
Sellers have to keep stock counts current so buyers do not order items that are gone. Overselling something that is out of stock is one of the fastest ways to create an unhappy buyer and a refund, so inventory tracking, low stock warnings, and the ability to mark an item unavailable all belong in the seller tools. This is quiet plumbing, but it prevents a very common category of complaint.
Pricing and promotions
Pricing is where sellers compete on a discount marketplace, so they need clear control over prices and the ability to run their own discounts and sales. Some platforms surface especially cheap or discounted items more prominently, which gives sellers a reason to price keenly. However you design it, sellers need to see and adjust their prices easily, because on a bargain platform price is the main lever they pull.
Fulfilment and shipping
Once an item sells, the seller has to pack and ship it, then mark it as sent and provide tracking. Because a single buyer order can contain items from several sellers, each seller only ever handles their own part, and the platform stitches the shipments together in the buyer's order view. Clear fulfilment tools, deadlines, and tracking entry keep the whole thing honest and keep the buyer informed.
Seller performance and standing
You want good sellers to thrive and poor ones to improve or leave, so sellers need to see how they are doing: their sales, ratings, dispute rate, shipping speed, and any warnings. This standing can feed into how much visibility their products get in the feed, which gives sellers a strong incentive to ship quickly, describe items honestly, and keep buyers happy. A visible, fair scorecard is one of the best tools you have for raising quality across a large seller base without policing every listing by hand.
The seller experience is usually delivered through a seller app or a web dashboard, or both. Many sellers manage their business from a computer, so a web dashboard is common, while a companion app helps them respond to sales and messages on the go. We can advise on the right mix for your sellers as part of scoping. For a related take on empowering independent sellers, our guide on how to build an app like Etsy is worth a read.
The discovery and recommendation engine
If the discovery feed is the heart of the buyer app, the recommendation engine is the muscle behind it. This is the system that decides which of your enormous, ever changing catalogue to show each person, in what order, so the feed feels personal and keeps them scrolling. On a discount marketplace this is not a nice extra, it is the core product, because nobody can browse a catalogue this big by hand. The engine is what turns a chaotic pile of cheap goods into a feed that feels made for you.
Why the feed is not search first
A search first shop assumes intent: you know what you want, you type it, you get results. A discount marketplace assumes curiosity: you do not know what you want, you are browsing for a bargain, and the app's job is to surface something cheap and appealing before you lose interest. That is why the feed leads. The whole experience is built to reward scrolling with a steady stream of items you are likely to tap, which is a fundamentally different design goal from a search box.
What the engine learns from
The engine improves by watching behaviour. Every tap, save, add to cart, purchase, search, and even how long someone lingers on an item is a signal. It combines what this person has done with what similar people liked, and with the qualities of the products themselves, to predict what to show next. Early on, before you have much data, the feed leans on simple rules like popularity, category, and price. As usage grows, it gets more personal. This is why launching and gathering real behaviour matters so much: the engine is only as good as the data it learns from.
Building it in the right order
A common mistake is to try to build a sophisticated recommendation system before there is any usage to train it. That is backwards. In a first version, a sensible approach is a feed driven by clear rules: trending items, fresh listings, category matches, keen prices, and a buyer's own recent activity. That already feels responsive and personal enough to launch. Once you have real behaviour flowing in, you invest in smarter personalisation. Simple and shippable first, clever later, is the right sequence, and it keeps your first build focused and affordable.
Keeping the feed fresh and fair
Two forces you have to balance in the feed are freshness and fairness. Freshness keeps the feed interesting so returning buyers see new things rather than the same items every day. Fairness means new sellers and new listings get some exposure, otherwise only established items ever show and your supply side stalls. A feed that only ever shows the same bestsellers slowly starves new sellers of sales and goes stale for buyers, so building in a little rotation and a little discovery of the new is worth doing deliberately.
Global logistics and shipping times
A defining trait of a Wish style marketplace is that goods often ship a long way, and delivery can take a while. Many low-cost sellers are far from their buyers, so a bargain that arrives in weeks rather than days is normal for this category. This is not a bug you need to engineer away, it is a characteristic of the model, and your job is to set expectations honestly and keep buyers informed while they wait.
Setting delivery expectations up front
Because shipping can be slow, the app has to be honest about it before the buyer pays, not after. Each product should show a realistic delivery estimate, and checkout should confirm it, so nobody is surprised. Bargain hunters accept a longer wait in exchange for a low price, but only if they knew about it going in. An optimistic estimate that slips is one of the fastest ways to turn a happy buyer into a refund request and a bad review, so honesty here protects both trust and your support load.
Order tracking across many shipments
Since one order can contain items from several sellers, each on its own journey, tracking has to work per shipment, not per order. The buyer sees each item's status and estimated arrival, even though they made a single purchase. This is one of the more fiddly parts of a discount marketplace, because you are stitching together tracking from many sources into one clear picture, but it is exactly what keeps a buyer calm during a long wait.
Working with carriers
You do not build shipping yourself. Sellers ship through carriers and postal services, and the platform records the tracking they provide. As you grow, you can integrate with shipping and tracking services to pull status updates automatically rather than relying on sellers to update by hand, which makes tracking more reliable. In a first version, capturing tracking numbers from sellers and letting buyers follow the link is often enough to launch and learn.
Managing the long wait
The stretch between purchase and delivery is where a lot of anxiety and support questions live, so the app should fill it with reassurance: clear status, honest estimates, and easy access to help if something is genuinely late. Some platforms send gentle updates along the way so the buyer feels looked after rather than forgotten. Handling the wait well is a real part of the product on a marketplace where waiting is normal, and it is where you either build patience and trust or lose both.
| Shipping concern | What the app does | Why it matters |
|---|---|---|
| Long delivery times | Show honest estimates before payment | Bargain buyers accept waits they knew about |
| Items from many sellers | Track each shipment separately | One order, several arrivals, one clear view |
| Uncertain status | Pull carrier updates and notify the buyer | Fewer worried support questions |
| Late or lost items | Clear path to help, refund or reship | Recovering well keeps buyers coming back |
Payments and multi-seller payouts
Money on a discount marketplace flows in a particular shape that founders should understand early, because it is more involved than a single shop taking a single payment. The buyer pays once for a cart that may contain items from several sellers. That one payment then has to be split so each seller is paid for their part, the platform keeps its fee, and everything reconciles correctly. This is the multi-seller payout problem, and getting it exactly right is essential to keeping sellers' trust.
Taking the buyer's payment
On the buyer side, payment has to be quick and reassuring, because any friction kills an impulse purchase. The buyer pays once for the whole cart using a card or a digital wallet, handled through an established payment provider. Using a proven provider keeps sensitive card data off your own systems and is both safer and faster than building payment handling yourself. Our guide on payment app development covers this in more detail.
Splitting money to many sellers
Behind that single payment, the money has to reach each seller who contributed to the order, minus the platform's fee. Modern payment providers support this kind of split and payout to many recipients, which is why you build on one rather than trying to move money yourself. The platform records who is owed what, when items ship or are confirmed, and pays sellers accordingly. This ledger has to be accurate, because sellers watch their payouts closely and lose faith fast if the numbers are wrong.
Holding funds until fulfilment
Because buyers are trusting unknown sellers, many marketplaces do not release a seller's money the instant the buyer pays. Instead they hold it until the item has shipped, or in some cases until it is confirmed delivered, so there is protection if the seller never sends the goods. This kind of hold protects buyers and keeps the marketplace trustworthy, at the cost of some extra logic in how and when payouts are released. Deciding on your hold policy is a real design choice with consequences for both trust and seller happiness.
Refunds and chargebacks
On a discount marketplace, some orders will need refunding, whether because an item never arrived, arrived broken, or did not match its description. The payment system has to handle refunds cleanly, including working out whether the seller or the platform bears the cost, and coping with card chargebacks when a buyer disputes through their bank. This is detailed work, but it is central to a marketplace where buyers need confidence that a cheap purchase from an unknown seller is safe. Planning refunds as a core flow, not an edge case, saves a great deal of pain later.
Trust, quality and returns
When you have many sellers you have never met, and buyers taking a chance on cheap goods from strangers, trust becomes the thing that makes or breaks the marketplace. A single well known shop earns trust through its brand. A marketplace of hundreds of small sellers has to build trust through systems: ratings, reviews, quality checks, and a fair way to handle it when something goes wrong. This is where a lot of the real work of running a discount marketplace lives.
Ratings and reviews
Ratings and reviews do much of the trust building. Buyers rate sellers and products, leave photos and comments, and read others' before buying. This gives new buyers confidence, helps good sellers stand out, and gives you a signal for which sellers deserve more visibility and which need watching. Because reviews carry so much weight on a bargain platform, protecting them from fakes and abuse matters, so they stay a signal buyers can rely on rather than noise anyone can game.
Quality control across many sellers
With a large seller base, some listings will be inaccurate, some items will be poor, and a few sellers will behave badly. You cannot inspect every item, so you build systems that catch problems: monitoring seller ratings and dispute rates, flagging listings that draw complaints, and acting on sellers who repeatedly disappoint. The goal is not perfection, it is keeping quality high enough that buyers keep trusting the platform, and doing it at scale without hand checking every listing.
Returns and disputes
Sometimes an item is wrong, broken, or never arrives, and the buyer wants their money back. A clear returns and dispute process is essential, and it has to be fair to both sides. The buyer needs an easy way to report a problem and get a resolution. The seller needs a fair chance to respond. And you, the platform, are the referee, often stepping in through your admin tools to decide. Handling disputes fairly and quickly is one of the strongest trust signals a marketplace can send, because buyers will forgive a bad item if the platform makes it right.
The admin and moderation panel
All of this runs on an admin panel: the control room where you oversee sellers, watch quality signals, handle disputes, issue refunds, and remove bad actors. This piece is easy to underestimate, but it is how you actually run and police the marketplace day to day. A good admin panel is what lets a small team keep a large marketplace honest, so it deserves real attention rather than being treated as a back office afterthought. Our guide on ecommerce app development touches on the operational side of running a store at scale.
Technology stack
Here is a sensible shape for the technology behind a discount marketplace app, described for a founder rather than an engineer.
The buyer app
The buyer app is mobile first, because impulse shopping happens on phones. You can build native or use a cross platform framework to share most of one codebase across iOS and Android, which frequently saves time and cost. Given that you will likely build buyer and seller apps, that saving adds up, so cross platform is worth serious consideration. Our guides on building a marketplace app and building an ecommerce app go deeper on the choices.
The seller tools
Sellers often manage their business from a computer, so the seller side is frequently a web dashboard, sometimes paired with a companion app for sales alerts and messages on the go. The right mix depends on who your sellers are, which is something we work out with you during scoping.
The backend and catalogue
The backend holds the huge, constantly changing catalogue, the accounts, the orders, and the money records, and it runs the logic that ties everything together. Because the catalogue is large and the feed has to be quick, search and browse are usually powered by a dedicated search and indexing system so results and feeds load fast even with a big catalogue. This is the technical backbone of the marketplace.
The recommendation engine
The discovery feed is powered by the recommendation engine described earlier. In a first version this can be rule based, running on the same backend. As you grow and gather behaviour data, it becomes a more dedicated system that personalises the feed. Building it in stages keeps the first version affordable while leaving room to get smarter.
Payments
Payments and multi-seller payouts run through an established provider that supports splitting one payment across many sellers and holding funds until fulfilment. Using a proven provider is safer and faster than building payment handling yourself, and it keeps sensitive card data off your systems.
Notifications and analytics
Push notifications keep buyers informed about orders and tempt them back with new items, and keep sellers on top of sales. These run through the platform services from Apple and Google. Analytics tie the whole thing together, telling you what buyers tap, which sellers perform, and where the experience breaks, so you can improve the feed and the marketplace over time. On a marketplace this data is not a luxury, it is how the discovery engine learns.
MVP scope and timeline
Because a discount marketplace has two sides, a discovery engine, payments, and logistics, a disciplined minimum viable product matters more than usual. The goal of the first version is to prove the model in a focused way: sellers can list cheap products, buyers can discover and buy them, money reaches sellers correctly, and items get shipped and tracked. Everything beyond that can wait.
A sensible MVP covers the essential loop on both sides. Sellers can create listings, manage stock, set prices, and mark items shipped. Buyers get a discovery feed, product pages, search, a cart across sellers, fast checkout, and per shipment tracking. You get an admin panel to oversee sellers, handle disputes, and issue refunds. Crucially, the discovery feed can start rule based rather than a sophisticated personalised engine, and you can capture tracking from sellers rather than integrating every carrier on day one. Proving the loop is the job, not building every advanced feature.
Features that can come later include advanced personalised recommendations, automated carrier integrations, seller promotions and coupon engines, in app messaging between buyer and seller, wish lists and social sharing, and support for many currencies and regions at once. Each adds scope, and none is needed to learn whether your marketplace works. Trying to build the full platform before proving the core loop is the most common way these projects overspend. Our guide on building a marketplace app and our look at a deal driven cousin, how to build an app like Groupon, are useful companions here.
On timing, because you are building two sides plus a feed and payments, a discount marketplace MVP generally takes longer than a single app product, often in the range of four to seven months to design, build, and test to a launch ready standard. The exact length depends on how polished each side needs to be and how many advanced features you include at launch. A fuller platform with personalised recommendations, carrier integrations, and multi region support is additional time, built in stages after the core loop is working.
| Phase | What happens | Rough duration |
|---|---|---|
| Discovery and design | Define the category, map buyer and seller flows, design the feed | A few weeks |
| Core build | Buyer app, seller tools, catalogue, feed, cart, payments, tracking, admin | The bulk of the project |
| Testing and hardening | End to end buying, multi-seller payouts, tracking accuracy, refunds | Several weeks |
| Launch and iterate | Go live in a focused category, watch real behaviour, tune the feed | Ongoing |
We never publish prices, because the only number worth planning around is a quote for your exact idea, and cost depends entirely on scope. A focused MVP costs far less than a full platform. The choices that move cost most are how polished each side is, how sophisticated the recommendation engine is at launch, how much of logistics and carrier integration you build early, and how many extra features you include. Starting with one category and a focused MVP gives you a great deal of control over the budget. To get a figure you can plan around, tell us your idea and let us scope it. See how we work on our pricing page.
Common mistakes
These are the mistakes we see most often in discount marketplace projects, and each one is avoidable.
Building a shop instead of a marketplace
Founders sometimes design a single tidy catalogue and only later realise they need seller tools, a discovery feed, and multi-seller payouts. A discount marketplace is a two sided business from the start, so plan for both sides and the feed that connects them, not just a pretty storefront.
Putting search before discovery
Copying a normal shop's search first layout misses the point of this category. Bargain hunters browse for fun, so the feed should lead and search should support it. Getting this ordering wrong makes the app feel like a catalogue rather than a hunt, and it loses the impulse energy that drives sales.
Overbuilding the recommendation engine too early
A sophisticated personalised feed is hard to build well before you have any behaviour to learn from. Start with a sensible rule based feed, launch, gather real data, and invest in smarter personalisation once it can pay off. Clever before you have data is wasted effort.
Ignoring the seller experience
If listing is painful and payouts are unclear, sellers list less and leave, the feed goes stale, and buyers follow. The seller side is half the marketplace, so give the listing tools, inventory, and payouts the same care as the buyer app.
Being dishonest about shipping
Hiding long delivery times to win a sale backfires when the item is late. Bargain buyers accept a wait they were told about, but feel cheated by one they were not. Set honest expectations before payment and keep buyers informed while they wait.
Treating trust and disputes as an afterthought
On a marketplace of strangers, ratings, buyer protection, and fair disputes are core product, not back office. Skimp on them and buyers stop trusting cheap purchases from unknown sellers, which is the whole basis of the business. Build these in from the first version.
Build your app with us
Building an app like Wish means building a two sided discount marketplace: a discovery feed that surfaces cheap goods to bargain hunters, seller tools that keep the feed stocked, payments that reach many sellers correctly, honest logistics, and the trust systems that let strangers buy from strangers. It is more involved than a single shop, but it is very achievable with the right plan: pick a focused category, build a disciplined MVP across both sides, start the feed rule based, and grow from a loop that works. The technology is well understood, and the craft is in the discovery, the money flow, and the judgement about what to build first.
That is our specialty. mobileapplication.ca is a Canadian app development company with senior engineers who have built marketplace and ecommerce products. We give fixed scope quotes so you know what you are getting, you own all the code we write with no lock in, and we build in stages so you can launch in one category and expand as it works. See our recent work and our mobile app development services to learn more.
If you are early in your thinking, a good first conversation is simply which product category and which sellers to start with, because getting that focus right shapes everything else. We would rather help you launch something tight in one category than build a sprawling marketplace that takes a year to reach anyone. Bring us the idea and we will tell you honestly what we would build first and why.
The first step is free. Tell us about your marketplace idea, your category, and what the first version should do, and we will come back with a plan, a timeline, and a fixed scope quote. No pressure, no obligation.