Powstania Warszawskiego 15
31-539 Kraków
A marketplace MVP has a problem no other product has: it is useless to each side until the other side shows up. Most founders try to solve that by building more features for both. The ones who succeed usually build less, for one side first, and do the rest by hand. This guide shows how to decide which side, and what can stay manual.
A marketplace MVP should cover one complete transaction between the two sides and nothing more. Build first for the side that is harder to attract: if providers are scarce, give them tools worth using even without customers; if customers are scarce, make their first experience excellent and recruit providers yourself. Matching, onboarding, payments and moderation can all start as manual work by the founder. Automate each one only when doing it by hand stops scaling.
Place your marketplace in one of four corners. The answer decides where the first version spends its effort.
Give providers a tool they would use even with no customers yet, such as scheduling or profiles. Customers will come once there is supply.
Start with one city, one category or one type of job, small enough that you can recruit both sides personally.
When supply and demand both exist, the product is the quality of matching and the trust between strangers.
Make the first search, booking or purchase excellent. Onboard providers by hand so the customer side never looks empty.
Every item below can be automated later. In the first months, doing it manually is faster to build, cheaper to change, and teaches you how the marketplace really works.
Suggest the right provider to each early request yourself, by message or a simple admin view.
Automate when requests outnumber your timeCall, verify and set up the first providers personally, so quality is controlled from day one.
Automate when sign ups arrive dailySettle early transactions outside the app or by invoice while you learn how people buy.
Automate when manual billing slows salesReview listings and resolve disputes yourself from an admin view.
Automate when volume makes review a full time jobThis is the same principle we use for any first version: at low volume, the founder can be the admin. A simple panel and a few manual steps cost a fraction of full automation and buy months of learning.
Loopy Jobs is a two sided marketplace built in Flutter with a Supabase backend, with real time chat, location matching and a booking system built so two people never take the same slot. It started as one booking flow.
Automated payments, company profiles and subscriptions were moved to version two before development started. The product has since passed 4000 users on a backend that did not need rebuilding to get there.
What usually waits: automated payouts, reviews and ratings, subscriptions for providers, advanced search filters and analytics dashboards. More on scoping the first version in MVP app features.
How we build two sided products end to end is described on our marketplace app development page. If your marketplace is built around appointments or slots, see booking app development, and for planning a first version on a fixed budget, MVP development for startups.
One complete transaction between the two sides: one side lists or offers, the other finds and books or buys, and both can confirm it happened. Profiles, search, a way to communicate and basic trust signals usually belong in the first version. Advanced payments, reviews, subscriptions and analytics can often wait.
The side that is harder to attract. If providers are scarce, build tools they would use even without customers. If customers are hard to win, make their first experience excellent and recruit providers by hand. Many successful marketplaces start by serving one side well before the network effect exists.
Often, yes. Early transactions can be settled outside the app or invoiced manually while you learn how people actually buy. Automated payments, payouts and fees add significant scope and store considerations, so many teams add them once the core transaction works.
A first version built around one transaction typically takes 8 to 12 weeks from kickoff. Payments, reviews and admin tools extend that, which is why deciding what to leave out matters so much.
We price a fixed scope after a scoping call and a written scope document, so the number is agreed before development starts. This article does not quote figures. Current information is on our pricing page.
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Tell us who the two sides are and which one is harder to win. We will tell you what the first version should cover and what can stay manual.