Marketplace app development is the engineering of two-sided products — apps where one group offers something and another group finds it: services, rentals, gigs, second-hand goods, on-demand help. It differs from ordinary app development in one structural way: you are shipping two products that must launch as one. Every feature exists twice from different angles — a listing is created by one side and browsed by the other, a booking is requested by one and accepted by the other — and the product only works when both experiences do.

Flutter fits this shape well for a blunt economic reason: a marketplace already carries double product surface, and paying double platform cost on top of it is how two-sided budgets die. One codebase covers buyer and seller flows on both iOS and Android — and where the two roles diverge enough to become separate apps, both still come from the same code, the same way our white-label fleet does it.

The products we build

  • Local services marketplaces — providers and seekers in the same area, as in OneTwoDo, which we designed and shipped end to end
  • On-demand products — request, match, fulfill: cleaning, repairs, delivery-style workflows
  • Rental and booking marketplaces — inventory with calendars, availability, and the double-booking problems they bring
  • Peer-to-peer goods — listings, offers, and the chat where the actual deal happens
  • B2B and niche marketplaces — where supply is curated and onboarding one side is an operations problem the app must support

Who Builds Your Marketplace App

A live marketplace, designed and shipped in seven weeks

OneTwoDo is a two-sided local services marketplace for Perform Connect Studios S.L. — cleaning, repairs, plumbing and more, posted by providers and browsed by neighbors. We built the whole product: the design, the Flutter client, and everything it runs on. Multi-currency pricing, per-listing localization, and a feed filtered by language and location shipped inside those seven weeks, in 2024.

The build is also a worked example of marketplace scoping done honestly. A two-sided product normally implies a backend team before anything else; OneTwoDo shipped without writing that layer — Firebase for accounts, listings, photos, and analytics — which is what let one team carry design, client, and backend at once. Whether that architecture fits your marketplace is a scoping question we answer before the estimate, because it moves both the number and the calendar. The MVP page tells the same story from the validation angle.

The adjacent muscles: feeds, chat, real-time

A marketplace is usually a feed plus a conversation plus a transaction. We have shipped each at production depth: Jepta's location-aware feed and real-time chats and channels, Arcana's streaming chat holding thousands of messages at 60 fps, and the payments discipline described on our fintech page — led by a founder who ran card processing at scale.

What Marketplace Apps Actually Demand

The cold-start problem is a product decision the app must serve

Every marketplace opens empty, and the app either helps or makes it worse. Helping looks concrete: a browsing experience that is useful before critical mass (curated categories rather than a barren search box), supply-side onboarding so low-friction a provider lists in minutes from a phone, and geographic focus built into the data model — winning one neighborhood beats being empty everywhere, which is why OneTwoDo's feed filters by location and language at the query level rather than as an afterthought.

Two roles, one codebase — decided deliberately

One app with a role switch, or two apps from shared code? The answer is per-product: a role switch when most users may eventually do both (peer-to-peer goods), separate apps when the provider side is a work tool with its own workflows (on-demand fleets). We have shipped the machinery for both — the cashback platform's consumer fleet and its separate merchant app come from one codebase. What stays constant is that both sides are specified together, because every marketplace feature is one flow crossing two screens owned by different people.

Search and matching are the product

Buyers judge a marketplace by whether the first screen shows something relevant. That is server-side work — indexed search, filters that mirror how supply is actually described, ranking that balances freshness, proximity, and quality — surfaced through a client that keeps scroll position stable under pagination and renders image-heavy cards without stutter on mid-range hardware. The catalog mechanics overlap our e-commerce page; the difference is that marketplace inventory is messy, user-generated, and always partly stale, and the UX has to absorb that.

Trust machinery: reviews, profiles, chat

Strangers transact when the app gives them reasons to. Verified profiles, reviews that resist retaliation and spam, and in-app chat where the deal actually happens — with photos, offers, and enough structure that support can later reconstruct what went wrong. Chat is real-time engineering (typing, delivery, reconnection over a ), and moving conversations off-platform is a leak the design has to price in, not a moderation rule that fixes itself.

Payments, payouts, and the money in between

Marketplace money is harder than shop money: a payment comes in, a commission is held back, a payout goes out, and a dispute can happen at any point in between. Provider choice matters more than UI here — marketplace-grade rails like Stripe Connect exist precisely so escrow-shaped flows and seller onboarding (with its KYC obligations) are the provider's compliance problem rather than yours. Amounts are integers in minor units end to end, per the rule that never bends. And both stores take no cut of physical goods and real-world services — but the moment you sell digital items, in-app purchase rules apply, and the line is worth drawing during scoping rather than during review.

Store review with user-generated content

Listings, photos, chat, and reviews make a marketplace UGC by definition, and Apple's guideline 1.2 requires the full apparatus: content moderation, a report mechanism, user blocking, and published terms. Teams discover this in the final week and ship late; we budget it as scope, together with account deletion and the data-safety declarations both stores demand.

Why Flutter for a Marketplace

RequirementHow Flutter handles it
Two roles × two platformsOne codebase where native would mean four builds' worth of surface
Both stores at launchSupply and demand rarely share a platform; missing one store halves a two-sided funnel
Image-heavy feeds on cheap phonesNative-compiled rendering keeps listing grids smooth on mid-range Android
Chat that feels instantA real-time layer built once serves both roles — proven on Jepta and Arcana
A v1 that can iterate weeklySub-second hot reload while you learn what your liquidity actually needs

Where native still wins: if the product is essentially one platform's capability — an App Clip-first flow, deep platform-specific hardware — the cross-platform saving is not the point, and we will say so. The general service page is Flutter app development.

How We Work

Fixed-scope build. We own delivery end to end — discovery, design, architecture, build, store submission. OneTwoDo is this model. Our development process describes it week to week.

Staff augmentation. Our engineers join your existing team, in your repo and your sprints — see team augmentation.

Either way, we send a scoped quote within two business days of understanding the requirements.

What a Marketplace App Costs

A first release that proves liquidity — listings, search, profiles, chat or booking, one payment flow — is typically an -to-Business-tier build: from $15–30K for a lean managed-backend validation build like OneTwoDo, to $30–60K over three to five months when the product needs its own backend, reviews, and payout flows. Separate provider apps, marketplace-grade payment rails with escrow, or operations tooling push into enterprise territory: from $90K+.

These are the same published tiers as on the Flutter app development page — a vertical does not get a second price list. What moves a marketplace number within them: whether the two roles are one app or two, how much matching intelligence v1 really needs, and where between "link to Stripe checkout" and "held funds with payouts" your money flow sits.

Frequently Asked Questions

Common questions from founders building two-sided products on Flutter.

Yes, and the argument is structural: a marketplace already doubles your product surface because every feature exists for both a supply side and a demand side, and Flutter stops you paying double platform cost on top of that. One codebase covers buyer and seller flows on iOS and Android, image-heavy listing feeds stay smooth on mid-range devices because Flutter compiles to native code, and the real-time chat layer a marketplace needs is built once. We designed and shipped OneTwoDo, a live two-sided services marketplace, in seven weeks on exactly this stack.
A lean first release on a managed backend starts at our published MVP tier, a marketplace with its own backend, reviews, and payout flows is a Business-tier build over three to five months, and separate provider apps or escrow-style payment rails price as enterprise work — the ranges are published on this page and the Flutter app development page rather than quoted privately. The three questions that move the number most: one app or two, how smart matching needs to be at launch, and how deep the money flow goes.
It depends on whether the seller side is an identity or a workplace. A role switch inside one app fits products where many users eventually do both, like peer-to-peer goods. Separate apps fit products where providers work in the app all day and need workflows buyers never see, like on-demand fleets. Both apps still come from one Flutter codebase — we run a fleet of fifteen consumer apps plus a separate merchant app from a single codebase, so the second app is an output of the build, not a second project.
The cold-start problem is won by operations and focus, but the app decides whether those efforts compound. Concretely: provider onboarding so light that supply lists from a phone in minutes, a browse experience that is useful before critical mass through curated categories rather than an empty search box, and geographic focus built into the data model so the product can win one area at a time. OneTwoDo's feed filters by location and language at the query level for exactly that reason.
Through marketplace-grade payment rails rather than a plain checkout: money comes in from the buyer, a commission is held back, a payout goes to the seller, and a dispute can interrupt any step. Providers like Stripe Connect exist to make seller onboarding, held funds, and the associated KYC obligations the provider's compliance problem instead of yours, and choosing that rail early is worth more than any amount of checkout UI. In the app, amounts are integers in minor units end to end, and payment state is owned by the server, never assumed by the client.
Treat a marketplace as user-generated content, because listings, photos, chat, and reviews make it one. Apple's guideline 1.2 expects a moderation method, a report mechanism, the ability to block users, and published terms — an app without them can be rejected regardless of how polished the rest is. Add the universal requirements, account deletion and data-safety declarations, and it becomes a real work package. We budget it as scope from the start, which is one of the reasons our submissions are a phase rather than a gamble.

Read the OneTwoDo case study for the full seven-week build, the timeline breakdown for where the calendar goes, or start from the Flutter app development pillar.