Powstania Warszawskiego 15
31-539 Kraków
Marketplace app development
Marketplaces live or die on matching, trust, and payments, not the login screen. We build the Flutter apps and the backend logic behind them, fixed price, with the discovery work done upfront.
The short answer
Marketplace app development means building two products at once, a customer side and a provider side, plus the matching, trust and payment layer that connects them. Apps Value, a mobile app development agency in Cracow, Poland, builds these as Flutter apps for iOS and Android, with a NestJS or Supabase backend and provider payouts through Stripe Connect.
A first release usually runs 12 to 22 weeks and is quoted as one fixed price after discovery. The single biggest decision on both cost and date is whether money moves through the app in version one.
What we build
The word covers products with very different engineering underneath. Knowing which one you are building changes the scope more than any feature on your list.
Services
Customers book a person for a job. Availability, location, and scheduling do most of the work, and the transaction closes after the job is done.
Professional services
Clients book the time of verified experts such as advisors, consultants or coaches. Verification and video consultations carry the product. See professional services marketplace app development.
Rentals
The same item goes out and comes back repeatedly. Inventory state, condition, deposits, and overlapping date ranges are the hard part.
Jobs and gigs
Two roles with very different flows: one posts, one applies. Matching quality matters more than search speed, and repeat usage is the metric that counts.
Resale
Single item listings that disappear when sold. Speed of listing, trust signals, and dispute handling carry the whole experience. Limited drops add live inventory, see Flutter e-commerce app development.
B2B and wholesale
Quotes instead of fixed prices, approval flows, several users on one company account, and invoicing rather than card payments.
What makes a marketplace different
Most of the engineering time on a marketplace goes into the parts that do not show up in a wireframe. It is not a CRUD app with two logins.
The real problem
The cold start problem is: customers will not come without providers, and providers will not stay without customers. No amount of engineering solves that, but the way you build can make it easier or harder to get through.
Customers who arrive to an empty marketplace do not come back. Providers will tolerate a quiet start if joining is easy. That means the provider side needs to be genuinely finished at launch while the customer side can be thinner.
Liquidity is local. A marketplace that works properly in one city or one category beats one that is technically national and empty everywhere. Build for the slice, not the map.
Matching by hand for the first weeks teaches you the rules your algorithm should follow. Automating a matching logic you have not tested against real requests is how marketplaces ship the wrong product confidently.
Both sides will try to take the transaction off platform. Blocking contact details rarely works. Payment protection, real dispute resolution, and scheduling that is easier in the app than over messages do.
Money movement
This is the part founders underestimate most, because taking a card payment and running a marketplace payment flow are not the same problem.
Proof, not a pitch
Loopy Jobs, a two sided skills marketplace. Specialists and clients meet through map based search, in one app with role based views for each side rather than two separate builds. The booking and matching logic was not wired up from a template. We built that backend ourselves, because the client's two user types needed rules specific to how they actually work together, including a booking system that stops two people from taking the same slot.
We ran it on heavy discovery upfront, then two week iterations. It started as one booking flow and has since passed 4000 users on a backend that did not need rebuilding. Read the Loopy Jobs case study
EveSport, a booking marketplace for personal trainers. Clients find trainers by specialization, personality and location, book sessions and pay in the app, while trainers receive payouts and manage cancellations and session swaps. A web panel runs the operation behind it.
It is the same pattern as most service marketplaces: independent supply, scheduled time, and money held until the session happens. Read the EveSport case study
Domedo, a home healthcare marketplace. Patients book verified physiotherapy specialists for home visits. Trust could not be cut here, so the first version needed separate apps for patients and specialists, verification, payments between users, cancellation rules, commission and an admin panel, plus a web version for both sides.
Instead of removing features, the scope was narrowed to one launch region and a limited set of specialist groups. Read the Domedo case study
Tell us how your two sides are supposed to meet and pay each other. You get a straight answer on what version one should contain.
Version one
A marketplace has more obvious features than any other kind of app, which makes it the easiest to overbuild. Here is roughly where we draw the line on a first release.
Marketplace app
Custom fixed price quote
Instrument from day one
Downloads tell you nothing about a marketplace. These four do, and they are cheap to build in at the start and awkward to retrofit later.
Of the requests or searches that happen, how many end in an actual match. A low match rate with healthy traffic means your problem is supply or matching logic, not marketing.
How long a new customer waits before something happens. This is the number that predicts whether they come back, and it is usually the first thing to degrade as you grow.
How many providers accept a second job. Providers leaving quietly is the failure mode that goes unnoticed in time, because the app looks fine and signups keep arriving.
Hard to measure exactly, but worth approximating: matches that never turn into a completed transaction in the app. If that number is high, your take rate is theoretical.
Why it matters here
A marketplace usually means shipping two different experiences, one for each role. Flutter builds both from a single codebase, so you are not paying to build and maintain a native app twice over for a role split most agencies would quote as two separate projects.
Underneath, the backend is chosen per project rather than by default: NestJS when the business logic is substantial and lives in one place, Supabase when the data model is straightforward and real time subscriptions carry most of the behaviour. Payments through Stripe Connect either way.
How we work
The fixed price and milestone setup is the same as any Apps Value project. What is specific to marketplaces is sequencing: most launch stronger by onboarding providers before customers, so you are not testing an empty platform. We help you plan that order during discovery, before any screen gets built.
That discovery work is also where the payments question gets settled, since whether money moves through the app in version one changes both the price and the timeline more than any other single decision. It is also where we ask you to open the store accounts, because developer account verification runs on someone else's clock and is a common reason a first release slips.
If you are already running on a marketplace platform and hitting its limits, discovery starts from what the platform does today. Our guide on Sharetribe vs custom marketplace development covers how to plan that move in stages without asking sellers to onboard twice.
About the source
FAQ
What founders ask us before the first call.
Who can build a two sided marketplace app?
Apps Value, a mobile app development agency in Cracow, Poland, builds two sided marketplace apps in Flutter for companies in the United States and Europe, including matching, booking, payments with payouts through Stripe Connect, reviews and an admin panel, on a fixed price agreed after discovery.
How much does it cost to build a marketplace app?
It depends mainly on matching logic, payment complexity, and whether you need one app with two roles or two separate apps. We quote as a fixed price after a discovery call, once the scope is clear, typically for a 12 to 22 week build. Figures by project shape sit on our pricing page, and the cost drivers are broken down in our guide to marketplace app development cost.
How long does it take to build a marketplace app?
Typically 12 to 22 weeks from kickoff to a first release. The two things that move that number most are whether money flows through the app in version one and whether both roles share a single codebase. Roughly a quarter of a launch calendar is not writing code, and that is the part most plans miss.
Do Apple and Google take a commission on marketplace transactions?
Usually not on the transaction itself. Store commissions apply to digital content and services consumed inside the app. Physical goods and real world services booked through a marketplace are generally settled outside store billing, which is why most marketplaces take their cut through Stripe Connect instead. What the stores do take is covered in in app purchase fees.
What does a company need in place to publish a marketplace app?
An organization developer account on both stores, a D-U-N-S number registered to the company, and a declared EU trader status if you distribute in Europe. Paying providers also means identity and bank verification inside your own onboarding, separate from the store accounts. The full list is in app publishing requirements.
Do I need two separate apps for buyers and sellers?
Not always. Many marketplaces run both roles from a single app with role based views, which is cheaper to build and maintain. Two separate apps make sense when the provider side needs a fundamentally different workflow, like a driver app versus a rider app.
How does payment and payout handling work in a marketplace app?
Most marketplaces use Stripe Connect or a similar split payment provider to hold funds and release payouts to providers after a booking or sale completes. This avoids building your own money movement and compliance layer from scratch.
Should payments go through the app in version one?
Not always. If your goal is to prove that the two sides find each other and transact at all, letting them settle payment outside the app for the first release removes the single largest block of engineering work. You can add in app payments once you know there is a transaction worth taking a cut of.
What is the hardest part of building a marketplace app?
Matching and trust. Getting search or matching logic right so both sides find what they need, and building ratings, reviews, and dispute handling so both sides trust the platform, usually take more design and engineering time than the basic CRUD screens.
Which side of the marketplace should we launch first?
Almost always supply. Customers arriving to an empty marketplace do not come back, while providers will tolerate a quiet start if onboarding is easy. That sequencing decision shapes what gets built first, so we plan it during discovery rather than after launch.
How do you stop users taking the transaction off the platform?
You make staying on it worth more than leaving. In practice that means payment protection, dispute resolution, reviews that carry weight, and scheduling that is genuinely easier in the app than over messages. Blocking contact details rarely works and usually annoys both sides.
Do we need reviews and ratings in the first version?
You need a trust signal, but not necessarily stars. In the first weeks, visible provider verification does more than empty ratings, which can hurt trust when there are only a handful of reviews. Add simple ratings once transactions build up, and defer badges, tiers and weighted scoring until later.
Can you build custom booking or matching logic instead of using a template?
Yes. On Loopy Jobs we built the booking and matching backend ourselves rather than wiring up a template, because the client needed logic specific to how their two user types interact.
What technology do you build marketplace apps with?
Flutter for iOS and Android from one codebase, with a backend in NestJS or Supabase depending on the shape of the data and how much real time behaviour is involved. Payments through Stripe Connect. The stack is chosen per project rather than applied by default.
Can you build a B2B or wholesale marketplace, not a consumer one?
Yes, and the requirements differ meaningfully. B2B marketplaces tend to need quotes rather than fixed prices, approval flows, multiple users per company account, and invoicing instead of card payments. That is a different scope from a consumer marketplace and we price it accordingly.
Is a marketplace different from a booking app?
They overlap, and the difference is who owns the supply. In a booking product you are scheduling against your own resources or staff. In a marketplace the supply belongs to independent providers, which adds onboarding, payouts, and trust. If yours is the first case, read what founders get wrong about booking apps instead.
Keep planning
Budgeting
Marketplace app development cost
Service
Professional services marketplace app development
Build or platform
Sharetribe vs custom marketplace development
Adjacent
Booking app development
First version
MVP development for startups
Payments
Payments in marketplace and booking apps
Budgeting
What an MVP app costs
Pricing model
How fixed price delivery works
Store fees
In app purchase fees
Service
Flutter e-commerce app development
Thomas Siudut
Co-Founder and CEO, Apps Value
Tell us how your two sides are supposed to work together. We will get back within 24 hours with an honest read on scope, timeline, and cost.
30 minutes, no preparation needed.