Marketplace-appontwikkeling is de engineering van tweezijdige producten — apps waarin de ene groep iets aanbiedt en de andere het vindt: diensten, verhuur, klussen, tweedehands spullen, hulp op afroep. Het verschilt op één structurele manier van gewone appontwikkeling: je levert twee producten op die als één moeten lanceren. Elke functie bestaat twee keer vanuit verschillende hoeken — een aanbieding wordt door de ene kant geplaatst en door de andere bekeken, een boeking wordt door de een aangevraagd en door de ander geaccepteerd — en het product werkt pas wanneer beide ervaringen werken.

Flutter past goed bij deze vorm om een botte economische reden: een marketplace draagt al een dubbel productoppervlak, en daarbovenop dubbele platformkosten betalen is hoe tweezijdige budgetten sneuvelen. Eén codebase dekt de koper- en verkoperstromen op zowel iOS als Android — en waar de twee rollen genoeg uiteenlopen om aparte apps te worden, komen beide nog steeds uit dezelfde code, precies zoals onze white-label-vloot dat doet.

De producten die we bouwen

  • Marketplaces voor lokale diensten — aanbieders en zoekers in dezelfde omgeving, zoals in OneTwoDo, dat we van begin tot eind ontwierpen en opleverden
  • On-demand-producten — aanvragen, matchen, uitvoeren: schoonmaak, reparaties, workflows in bezorgstijl
  • Verhuur- en boekingsmarketplaces — voorraad met kalenders, beschikbaarheid en de dubbelboekingsproblemen die daarbij horen
  • Peer-to-peer-goederen — aanbiedingen, biedingen en de chat waar de eigenlijke deal plaatsvindt
  • B2B- en nichemarketplaces — waar het aanbod gecureerd is en het onboarden van één kant een operationeel probleem is dat de app moet ondersteunen

Wie je marketplace-app bouwt

Een live marketplace, ontworpen en opgeleverd in zeven weken

OneTwoDo is een tweezijdige marketplace voor lokale diensten voor Perform Connect Studios S.L. — schoonmaak, reparaties, loodgieterswerk en meer, geplaatst door aanbieders en bekeken door buurtgenoten. We bouwden het hele product: het ontwerp, de Flutter-client en alles waarop het draait. Prijzen in meerdere valuta, lokalisatie per aanbieding en een feed gefilterd op taal en locatie werden binnen die zeven weken opgeleverd, in 2024.

De bouw is ook een uitgewerkt voorbeeld van eerlijke marketplace-scoping. Een tweezijdig product veronderstelt normaal eerst een backendteam; OneTwoDo verscheen zonder die laag te schrijven — Firebase voor accounts, aanbiedingen, foto's en analytics — en dat is wat één team ontwerp, client en backend tegelijk liet dragen. Of die architectuur bij jouw marketplace past is een scopingvraag die we vóór de offerte beantwoorden, omdat ze zowel het bedrag als de kalender beweegt. De MVP-pagina vertelt hetzelfde verhaal vanuit de validatiehoek.

De aangrenzende spieren: feeds, chat, realtime

Een marketplace is meestal een feed plus een gesprek plus een transactie. Elk daarvan hebben we op productiediepte opgeleverd: de locatiebewuste feed en realtime chats en kanalen van Jepta, de streamingchat van Arcana die duizenden berichten op 60 fps vasthoudt, en de betaaldiscipline die onze fintechpagina beschrijft — geleid door een oprichter die kaartverwerking op schaal draaide.

Wat marketplace-apps werkelijk vragen

Het koudestartprobleem is een productbesluit dat de app moet dienen

Elke marketplace opent leeg, en de app helpt of maakt het erger. Helpen ziet er concreet uit: een bladerervaring die nuttig is vóór kritieke massa (gecureerde categorieën in plaats van een kaal zoekvak), onboarding aan de aanbodkant zo drempelloos dat een aanbieder binnen minuten vanaf een telefoon iets plaatst, en geografische focus ingebouwd in het datamodel — één buurt winnen verslaat overal leeg zijn, en daarom filtert de feed van OneTwoDo op locatie en taal op queryniveau in plaats van als bijzaak.

Twee rollen, één codebase — bewust besloten

Eén app met een rolwissel, of twee apps uit gedeelde code? Het antwoord verschilt per product: een rolwissel wanneer de meeste gebruikers uiteindelijk beide rollen kunnen gaan vervullen (peer-to-peer-goederen), aparte apps wanneer de aanbiederskant een werkinstrument is met eigen workflows (on-demand-vloten). We hebben de machinerie voor beide opgeleverd — de consumentenvloot van het cashbackplatform en zijn aparte merchantapp komen uit één codebase. Wat constant blijft is dat beide kanten samen worden gespecificeerd, want elke marketplacefunctie is één stroom die twee schermen kruist met verschillende eigenaren.

Zoeken en matchen zijn het product

Kopers beoordelen een marketplace op de vraag of het eerste scherm iets relevants toont. Dat is werk aan de serverkant — geïndexeerd zoeken, filters die weerspiegelen hoe het aanbod werkelijk wordt beschreven, rangschikking die versheid, nabijheid en kwaliteit in balans houdt — ontsloten door een client die de scrollpositie stabiel houdt onder paginering en beeldzware kaarten zonder haperen rendert op middenklassehardware. De catalogusmechaniek overlapt met onze e-commercepagina; het verschil is dat marketplacevoorraad rommelig is, door gebruikers gemaakt en altijd deels verouderd, en de UX moet dat opvangen.

Vertrouwensmachinerie: reviews, profielen, chat

Vreemden handelen met elkaar wanneer de app ze daar redenen voor geeft. Geverifieerde profielen, reviews die bestand zijn tegen vergelding en spam, en in-app-chat waar de deal werkelijk plaatsvindt — met foto's, biedingen en genoeg structuur dat support later kan reconstrueren wat er misging. Chat is realtime-engineering (typen, aflevering, opnieuw verbinden over een ), en gesprekken die het platform verlaten zijn een lek dat het ontwerp moet inprijzen, geen moderatieregel die zichzelf oplost.

Betalingen, uitbetalingen en het geld daartussen

Marketplacegeld is moeilijker dan winkelgeld: er komt een betaling binnen, er wordt een commissie ingehouden, er gaat een uitbetaling uit, en op elk punt daartussen kan een geschil ontstaan. De keuze van de aanbieder doet er hier meer toe dan de UI — marketplace-rails zoals Stripe Connect bestaan juist zodat escrow-achtige stromen en verkopersonboarding (met de bijbehorende KYC-verplichtingen) het complianceprobleem van de aanbieder zijn in plaats van dat van jou. Bedragen zijn van begin tot eind hele getallen in de kleinste eenheid, volgens de regel die nooit buigt. En beide winkels rekenen geen commissie over fysieke goederen en diensten in de echte wereld — maar zodra je digitale items verkoopt gelden de regels voor in-app-aankopen, en die grens trek je beter tijdens de scoping dan tijdens de beoordeling.

Winkelbeoordeling met door gebruikers gemaakte content

Aanbiedingen, foto's, chat en reviews maken een marketplace per definitie UGC, en Apples richtlijn 1.2 vereist de volledige machinerie: contentmoderatie, een meldmechanisme, het blokkeren van gebruikers en gepubliceerde voorwaarden. Teams ontdekken dit in de laatste week en leveren te laat op; wij begroten het als scope, samen met accountverwijdering en de gegevensveiligheidsverklaringen die beide winkels eisen.

Waarom Flutter voor een marketplace

EisHoe Flutter dat aanpakt
Twee rollen × twee platformsEén codebase waar native vier builds aan oppervlak zou betekenen
Beide winkels bij lanceringVraag en aanbod delen zelden een platform; één winkel missen halveert een tweezijdige funnel
Beeldzware feeds op goedkope telefoonsNative gecompileerd renderen houdt aanbiedingsrasters soepel op middenklasse Android
Chat die direct aanvoeltEen realtimelaag die één keer is gebouwd bedient beide rollen — bewezen op Jepta en Arcana
Een v1 die wekelijks kan itererenHot reload in minder dan een seconde terwijl je leert wat je liquiditeit werkelijk nodig heeft

Waar native nog steeds wint: is het product in wezen de mogelijkheid van één platform — een stroom die met App Clips begint, diepe platformspecifieke hardware — dan is de cross-platformbesparing niet het punt, en dat zeggen we dan ook. De algemene dienstpagina is Flutter-appontwikkeling.

Hoe we werken

Bouw met vaste scope. Wij nemen de oplevering van begin tot eind voor onze rekening — verkenning, ontwerp, architectuur, bouw, indienen bij de winkels. OneTwoDo is dit model. Ons ontwikkelproces beschrijft het week na week.

Teamuitbreiding. Onze engineers sluiten aan bij je bestaande team, in jouw repo en jouw sprints — zie teamuitbreiding.

Hoe dan ook sturen we binnen twee werkdagen na het doorgronden van de eisen een afgebakende offerte.

Wat een marketplace-app kost

Een eerste release die liquiditeit bewijst — aanbiedingen, zoeken, profielen, chat of boekingen, één betaalstroom — is doorgaans een bouw van - tot Business-niveau: vanaf € 12-24K voor een slanke validatiebouw op een beheerde backend zoals OneTwoDo, tot € 24-48K, verspreid over drie tot vijf maanden, wanneer het product een eigen backend, reviews en uitbetaalstromen nodig heeft. Aparte aanbiedersapps, marketplace-betaalrails met escrow of operationele tooling duwen de bouw richting enterprisewerk: vanaf vanaf € 72K.

Dit zijn dezelfde gepubliceerde niveaus als op de pagina Flutter-appontwikkeling — een sector krijgt geen tweede prijslijst. Wat een marketplacebedrag daarbinnen beweegt: of de twee rollen één app zijn of twee, hoeveel matchingintelligentie v1 werkelijk nodig heeft, en waar tussen "linken naar een Stripe-checkout" en "ingehouden gelden met uitbetalingen" je geldstroom zit.

Veelgestelde vragen

Veelgestelde vragen van founders die tweezijdige producten op Flutter bouwen.

Ja, en het argument is structureel: een marketplace verdubbelt je productoppervlak al omdat elke functie bestaat voor zowel een aanbod- als een vraagkant, en Flutter voorkomt dat je daarbovenop dubbele platformkosten betaalt. Eén codebase dekt koper- en verkoperstromen op iOS en Android, beeldzware aanbiedingsfeeds blijven soepel op middenklassetoestellen omdat Flutter naar native code compileert, en de realtime chatlaag die een marketplace nodig heeft wordt één keer gebouwd. We ontwierpen en bouwden OneTwoDo, een live tweezijdige dienstenmarketplace, in zeven weken op exact deze stack.
Een slanke eerste release op een beheerde backend begint bij ons gepubliceerde MVP-niveau, een marketplace met een eigen backend, reviews en uitbetaalstromen is een bouw op Business-niveau verspreid over drie tot vijf maanden, en aparte aanbiedersapps of betaalrails in escrow-stijl worden als enterprisewerk geprijsd — de bandbreedtes staan op deze pagina en op de pagina over Flutter-appontwikkeling in plaats van dat ze privé worden genoemd. De drie vragen die het bedrag het meest bewegen: één app of twee, hoe slim het matchen bij lancering moet zijn, en hoe diep de geldstroom gaat.
Dat hangt ervan af of de verkoperskant een identiteit is of een werkplek. Een rolwissel binnen één app past bij producten waar veel gebruikers uiteindelijk beide rollen vervullen, zoals peer-to-peer-goederen. Aparte apps passen bij producten waar aanbieders de hele dag in de app werken en workflows nodig hebben die kopers nooit zien, zoals on-demand-vloten. Beide apps komen nog steeds uit één Flutter-codebase — wij draaien een vloot van vijftien consumentenapps plus een aparte merchantapp vanuit één codebase, dus de tweede app is een uitkomst van de bouw en geen tweede project.
Het koudestartprobleem wordt gewonnen door operationeel werk en focus, maar de app bepaalt of die inspanningen zich opstapelen. Concreet: aanbiedersonboarding zo licht dat aanbod binnen minuten vanaf een telefoon geplaatst is, een bladerervaring die vóór kritieke massa nuttig is via gecureerde categorieën in plaats van een leeg zoekvak, en geografische focus ingebouwd in het datamodel zodat het product gebied voor gebied kan winnen. De feed van OneTwoDo filtert precies daarom op locatie en taal op queryniveau.
Via betaalrails van marketplacekwaliteit in plaats van een gewoon afrekenproces: geld komt binnen van de koper, een commissie wordt ingehouden, een uitbetaling gaat naar de verkoper, en een geschil kan elke stap onderbreken. Aanbieders zoals Stripe Connect bestaan om verkopersonboarding, ingehouden gelden en de bijbehorende KYC-verplichtingen het complianceprobleem van de aanbieder te maken in plaats van dat van jou, en die rail vroeg kiezen is meer waard dan welke hoeveelheid afreken-UI ook. In de app zijn bedragen van begin tot eind hele getallen in de kleinste eenheid, en de betaalstatus ligt bij de server en wordt nooit door de client aangenomen.
Behandel een marketplace als door gebruikers gemaakte content, want aanbiedingen, foto's, chat en reviews maken hem dat. Apples richtlijn 1.2 verwacht een moderatiemethode, een meldmechanisme, de mogelijkheid om gebruikers te blokkeren en gepubliceerde voorwaarden — een app zonder die onderdelen kan worden afgewezen hoe gepolijst de rest ook is. Tel daar de universele eisen bij op, accountverwijdering en gegevensveiligheidsverklaringen, en het wordt een echt werkpakket. Wij begroten het vanaf het begin als scope, wat een van de redenen is dat onze indieningen een fase zijn in plaats van een gok.

Lees de casestudy van OneTwoDo voor de volledige bouw van zeven weken, de uiteenzetting van de planning voor waar de kalender heen gaat, of begin bij de pijler Flutter-appontwikkeling.