Marketplace app development

Why a marketplace is harder than a shop

A shop sells things you own. A marketplace sells access to things other people own, and that single difference multiplies the work. You do not control the stock, so listing quality becomes a process rather than a given. You do not control fulfilment, so a bad delivery is still your reputation. You hold money that is not yours between the buyer paying and the seller being paid. And you have the empty-room problem: buyers will not come without sellers, and sellers will not stay without buyers. None of that is a development problem, which is exactly why it belongs in the scope.

So a marketplace app is at least three products sharing one set of records: something for buyers, something for sellers, and a console for the people running the platform. It is a custom build shaped around your category, your commission model and your rules rather than a packaged marketplace we configure. Aruva Marketplace, Dwellfound, Voyaera and Hire Creative are our own concept prototypes of that shape in four categories. All four are prototypes rather than client work, and all four run as web platforms rather than published mobile apps.

Two sides, and whether they need two apps

Decide early whether buyers and sellers share one app with different modes or get separate products, because it changes the build, the store listings and the release cycle. One app with a role switch keeps a single codebase and suits categories where the same person does both, or where selling is occasional and light. Two apps make sense when the selling work is substantial and continuous, when each audience would be confused by the other's screens, or when you want to change the seller tools without putting every buyer through a store review first.

There is a third answer that is often the right one: the seller side is not an app at all. Listing management, pricing, order handling and finance are faster on a keyboard and a larger screen, and a seller at a desk does not want to do any of it by thumb. A common shape is a buyer app, a seller web workspace with a small phone companion for the things that genuinely happen while moving, and an operator console that is web only. The platform console is never an app.

Getting sellers on, and keeping the listings honest

Seller onboarding is where most marketplace scopes are thin. Treat it as a sequence of states rather than a form: applied, identity and business details verified, payout details collected and validated, agreement accepted, approved to list, suspended, removed. Every transition needs an owner and a record. Then decide how a listing becomes visible. Published immediately and policed afterwards grows supply and hands you a queue. Reviewed before it appears protects buyers and slows supply. Reviewed only above a risk threshold splits the difference. Whichever you choose, the review queue, the rejection reasons and the appeal route are part of the product rather than an operational detail to sort out later.

One marketplace, three steps

The table follows a fictional physical-goods marketplace through three steps. Roles, policies and responses are assumptions made for illustration, and the last column lists evidence to collect before sign-off rather than tests already passed.

Trust, moderation and disputes

If people can post content or message each other, moderation is a platform requirement as well as a commercial one. Apple's App Review Guidelines, read on 18 September 2026, require apps with user-generated content to include a method for filtering objectionable material, a mechanism to report offensive content with timely responses to concerns, the ability to block abusive users, and published contact information, and they state that removing content which violates the guideline or your own terms is your responsibility. That is Apple's guidance for its store on the date we read it rather than legal advice or a prediction of any review outcome, and it is worth rechecking before implementation. In practice it means a reporting route, a queue, a blocking mechanism and a named person are scope items from the first day.

Disputes are the same problem with money attached. Decide who decides: the platform, the two parties, or a rule applied automatically. Decide what evidence is admissible, where it is stored, who may see it and how long it is kept. Decide what happens to the payout while a dispute is open, because money released cannot be recalled by a support agent. And give every dispute a state both parties can see, because silence is what turns a disagreement into a public review.

Commission, payouts and whose money it is

Separate five things that get merged into the word payment: the buyer's order, the seller's fulfilment responsibility, the platform fee, the payment status and the payout. A marketplace usually collects from the buyer and pays the seller later, which means you are holding funds, and the obligations that come with that differ by structure and jurisdiction. Agree the commission model, when a fee is earned and when it is given back, the payout schedule, what is withheld against returns and disputes, and how a seller sees a statement they can reconcile. Then agree the identifier that ties an order, a payment and a payout together, because reconciliation without one is manual work forever.

Store policy touches this as well. Apple's guidelines, on the date read above, state that an app enabling people to purchase physical goods or services consumed outside of the app must use purchase methods other than in-app purchase. Whether your category counts as consumed outside the app is a judgement to check against the current wording rather than assume. The mechanics of taking and reconciling the money itself sit with payment and checkout, and the buyer-side discovery work with catalogue and search.

The failures that decide whether it can operate

Scope the exception paths as carefully as the happy path: a listing rejected or half uploaded, an order duplicated by a retry, a payment that fails after the seller has started packing, a delivery that never arrives, a message reported at midnight, a payout that bounces on bad bank details, and a seller who disappears mid-order. Each needs an owner, a state both sides can see, an audit trail, and an agreed piece of evidence to collect before you accept the build. Capacity is part of that. A report acknowledged immediately and answered in three days is honest; a report that silently waits is not.

What to bring to a scoping conversation

Bring the commercial model before the feature list: what is being sold and by whom, how a seller is approved, how you earn, when a seller is paid, who resolves a dispute, and what your category is sensitive about. Then bring the operational reality, which is usually the part nobody has planned: who will run the review queue, who answers reports, and how many of each you expect in a day.

Mobile app development covers the decisions common to any app, the core systems we build covers the accounts, catalogue and payment pieces underneath this one, and a scoped enquiry is the quickest route to an honest view of what is ready to build.