Two-sided mobile marketplace: what belongs in the MVP?

Short answer

A two-sided mobile marketplace MVP must support a real transaction between seller and buyer, with separate journeys, useful discovery, payment rules and basic support. The brief places that first version around €24,000 to €40,000 excluding VAT. With less to invest, a one-sided V0 can put only one group in the app while the founder runs the other side manually. It may test usage within an indicative €10,000 to €15,000 excluding VAT scope, as long as its limits are clear. The first question is not which features to copy. It is which transaction the product must prove.

Two audiences, two problems

A marketplace connects people looking for something with people offering it. The sides have different expectations. A provider wants credible requests and to know when they will be paid. A buyer wants a relevant offer, a clear price and someone to contact if things go wrong. Two sign-up forms do not solve that coordination problem.

The product needs to be useful before a complete market exists. If the app opens onto an empty catalogue, early buyers leave. If providers never receive a request, they stop updating listings. A founder can temporarily fill the gap by recruiting, qualifying and matching both sides manually. The mobile app specification should describe that manual work rather than hide it.

I would launch in one location, one category and one type of transaction. That is a commercial choice as much as a technical one. A nationwide app with ten categories looks ambitious but spreads supply thinly and slows learning. Scoping mobile MVP features starts by choosing the journey to prove before counting screens.

What a two-sided first release needs

The minimum differs by market, but both groups need an identity, a listing or request, a way to find each other and a clear state after contact. If payment is part of the promise, define who pays whom, when and who handles refunds. A dashboard attached to the mobile app can help the founder approve profiles, follow requests and resolve early incidents.

Element	Scoping question
Supply	Who publishes, verifies and expires a listing?
Demand	How does a buyer get a useful result without a huge catalogue?
Match	Which event counts: message, request or booking?
Payment	Who collects, who receives and when can a refund occur?
Operations	Which disputes can be handled manually at first?

Public ratings, instant chat and live location are not automatic requirements. They also bring moderation, notifications and edge cases. The first scope should deliver enough service to complete a transaction, then measure where people struggle. Our mobile app cost guide puts these workstreams in a broader budget.

A one-sided V0 does half the work manually

In a supply-led V0, providers use the app to manage a profile and receive requests. The founder can gather demand through an existing channel and route it by hand. Inyka does not build a standalone website for that channel; the mobile app remains the project. This version tests whether providers respond, keep details current and accept the leads.

In a demand-led V0, buyers browse a selection and submit a need in the app. The founder recruits providers and maintains the catalogue manually. This can be a good route when the hardest problem is creating a credible search experience. If nobody pays in that version, however, it tests interest and contact, not monetization.

Manual work is not a product failure. It exposes exceptions that automation would hide: unavailable supply, a quote needing clarification, a vague request or a cancellation. Record time spent per transaction. If the model fails with a small base and attentive operations, more code may only speed up a weak process.

Payments must match the real business model

A registration, click or message shows interest. A payment is a stronger signal of willingness to pay, but it adds operating obligations. Depending on the model, you may need seller identity checks, refunds, commissions and management of funds in transit. Do not call every such arrangement "escrow" without checking what the payment provider actually offers.

In France, the ACPR describes collecting funds on behalf of third parties as a regulated activity. A marketplace payment flow should be scoped with an appropriate payment provider and qualified advice where the arrangement requires it. Inyka can integrate a service such as Stripe Connect; it does not become a payment institution. The provider's onboarding and checks affect the schedule.

If the V0 has no payment, say plainly that it does not validate willingness to pay. A founder may seek that signal through a transaction operated outside the app, with the product and store rules checked for that specific flow. The technical quote must reflect the chosen model, not just a "Pay" button in a mock-up.

Features I would defer

Real-time chat is attractive, but asynchronous messages may work for early service requests. Constant provider location needs permissions, battery use and monitoring the model may not justify. Reputation scores are brittle when transaction volume is low; a handful of reviews can skew the ranking.

I would also defer complex commissions and automated dispute handling. Initially, a written rule and a documented manual process often teach more. Account deletion and contact routes still matter for publication: Apple requires apps that create accounts to let people initiate account deletion in the app.

The brief puts a one-sided V0 at about €10,000 to €15,000 excluding VAT and a two-sided V1 at about €24,000 to €40,000. These are planning ranges, not universal prices. At Inyka, a two-sided marketplace belongs at least in Scale, which starts at €24,000 excluding VAT. Our React Native service sets out the type of mobile products we build.

Mistakes that empty a marketplace before launch

Opening too many categories. A scattered catalogue looks large, but each specific search returns little. Start with a category and area where the team can actually confirm availability.

Counting registrations instead of transactions. Two waiting lists can grow without a single request being answered. Track qualified requests, responses and completed deals.

Letting providers publish without a quality rule. Incomplete prices, missing photos and inaccurate availability move work onto support. Set a minimum listing standard and review early submissions manually.

Adding chat to fix an unclear journey. If every buyer asks providers the same questions, the listing or request form is missing information. Repair that before funding a real-time conversation feature.

Learning refund rules from the first dispute. A successful charge is not a completed transaction. Write cancellation rules, name the decision owner and document the process with the payment provider.

What Inyka declines in this scope

• Calling a release a complete two-sided marketplace when one side is still operated by hand. A one-sided V0 is legitimate, but its scope needs an honest name.
• Promising "escrow" without confirming that the provider offers the actual function and that the payment setup fits the commercial flow.
• Banking, insurance or direct custody of customer funds. Inyka builds the mobile product and integrates an appropriate payment service; it does not provide regulated financial services.
• Two apps and a bespoke dashboard at the outset when one app and a limited attached administration tool can support the first transaction.

Scenario: a V0 with a clear learning goal

Consider a local services marketplace where providers are hard to recruit. The founder chooses one area and secures a checked initial catalogue before releasing a buyer app. The V0 lets people search, submit a request and follow its state. The founder contacts providers through existing channels, finds someone who responds and records the outcome. The brief puts that one-sided scope around €10,000 to €15,000 excluding VAT, subject to scoping.

During this phase, three measures matter more than installs: the share of requests answered by a provider, the time needed to find a suitable offer and the share of introductions that lead to a completed job. An unanswered request says something about provider recruitment, not necessarily the interface. If staff spend substantial time clarifying every request, the form may be too vague.

After repeated cycles, the founder can price automation of the provider side. They know which data to ask for, which states to show and which exceptions remain human. The two-sided V1 range in the brief, about €24,000 to €40,000 excluding VAT, then pays to implement an observed process. If V0 did not handle payments, the V1 quote needs a separate workstream for billing flow and refund tests. A button alone does not validate that model.

This scenario has a useful stop condition as well. If buyers repeatedly ask for services the catalogue cannot supply, adding provider dashboards will not create supply. The founder should recruit in that niche or narrow the promise. If providers answer quickly but buyers do not accept quotes, review price presentation and trust signals before building more chat or ranking features. Each outcome suggests a different next investment, and the product data should make that distinction visible.

Keep an operations log for each early transaction. Record how the request arrived, whether the listing described the service accurately, who answered, why the buyer accepted or declined and what support was needed afterward. The log should use consistent reasons rather than a free-form sentence nobody compares later. It becomes the specification for the next feature: a repeated availability problem points toward calendar data, while repeated uncertainty about the final price points toward clearer quote terms. Neither automatically calls for a second app.

The same record helps protect the budget. A feature request should refer to a pattern seen in real transactions and state the manual step it would remove. If a proposed change cannot be tied to a repeatable cost or a failed transaction, it can wait. That discipline keeps the mobile build focused while the founder learns how to attract both sides of the market.

Record these decisions with the next release scope so the team can challenge them later.

Give support staff the same transaction states that users see. If a buyer says "the provider accepted" while the support dashboard says "request pending," the team cannot resolve the issue quickly. Clear states and a short event history are more useful at launch than an elaborate analytics screen.

FAQ

Can a marketplace start without in-app payments? Yes, if the first test is about matching supply and demand. It does not yet prove that people will pay the intended price.

Do the two sides need separate apps? No. One app can serve two roles with different journeys. Two apps add publication, support and maintenance work.

Can the founder test an idea with no-code? The founder can choose their own tools to explore an idea. Inyka builds the mobile product with React Native and Expo and does not deliver no-code products.

Who handles disputes at launch? Name an owner, publish a rule and track cases. An automated interface does not make the commercial decision behind a refund.

When should the second side be automated? Once repeated transactions show which manual steps are consistent and how long they take. Earlier automation locks in untested assumptions.

Should every provider be verified before publication? The required checks depend on the service and user risk. At launch, manual review of the business identity and listing can reduce incomplete offers.

How do we judge search quality with a small catalogue? Track searches without results and abandoned requests. Those signals show where to recruit supply before adding more filters.

Are public ratings necessary from day one? Not always. A few early reviews can carry too much weight. Private incident tracking may be more useful until there is enough activity for public scores.

Scope the first transaction

Before commissioning two complete journeys, scope your marketplace MVP with Inyka. Bring one category, one launch area and the steps of a real transaction. That is enough to choose between a one-sided V0 and a two-sided V1.

Book a 30-minute discovery call to map supply, demand and payment for the first real use case.