E-commerce-appontwikkeling is de engineering van mobiele winkels — productcatalogi, winkelwagens, afrekenstromen, ordertracking en de loyaliteitsmechaniek die een klant laat terugkomen. Het verschilt op drie concrete punten van gewone appontwikkeling: de catalogus is groter dan het toestel (dus zoeken, caching en beeldlevering bepalen hoe de app aanvoelt), het afrekenen is de plek waar elk defect verandert in weggelopen omzet, en dezelfde winkel moet vaak meerdere keren bestaan — per merk, per markt, per valuta.

Flutter past ongewoon goed bij retail omdat het zijn eigen UI tekent: een productraster, een promotie in story-stijl of een eigen afrekenstroom gedraagt zich op iOS en Android identiek vanuit één codebase, tegen ongeveer 30–40% minder dan dezelfde winkel twee keer native bouwen. De delen die het platform rechtstreeks raken — de betaalschermen van Apple Pay en Google Pay, sommige SDK's van betaaldienstverleners — lopen via , wat routinewerk is maar wel echt werk.

De producten die we bouwen

  • Winkelapps — catalogus, zoeken, winkelwagen, afrekenen, ordertracking en reviews voor één merk
  • Loyaliteits- en cashbackapps — punten, beloningen en aanbiedingen, zoals in het cashback- en loyaliteitsplatform dat we bouwden en als vloot draaien
  • White-label-retailvloten — één codebase die per merchant of markt een merkapp oplevert; het platformwerk heeft zijn eigen dienstpagina
  • Apps voor de merchantkant — de tegenhanger die een verkoper of winkelmanager gebruikt, die we voor hetzelfde platform bouwden
  • Marketplace-winkels — waar de catalogus aan veel verkopers toebehoort; de tweezijdige dynamiek behandelen we op onze marketplacepagina

Wie je e-commerce-app bouwt

We zijn er eerlijk over wat ons portfolio bevat: geen winkel voor één merk die we bij naam kunnen noemen. Wat het wel bevat zijn de lastige delen van commerce, herhaaldelijk opgeleverd en nog steeds in productie.

Een vloot van vijftien merkapps voor consumenten

Voor een cashback- en loyaliteitsplatform onder NDA produceert één Flutter-codebase meer dan vijftien volledig gebrande apps — elk met een eigen naam, thema en winkelvermelding — plus de merchantapp aan de andere kant van elke transactie en een beheerpaneel dat een nieuw merk lanceert zonder engineeringwerk. Acht maanden bouwen, en de architectuur is uitgeschreven. Als je retailstrategie meer dan één winkel omvat, is dit exact de vorm van het probleem.

Betalingen, van binnenuit beheerd

Nerdy Production wordt geleid door Ilya Nixan, voorheen CTO van QIWI, een van de grootste betaalplatforms in zijn markt, waar zijn teams kaartverwerking draaiden en PCI-DSS-scope droegen. De relevantie voor een winkel is direct: afrekenen is een betaalkoppeling met een winkel eromheen, en de persoon die je bouw leidt heeft de andere kant van die koppeling beheerd. De disciplines die daarbij horen — geld als hele getallen in de kleinste eenheid, rechtenstatus die bij de server ligt, kaartgegevens buiten de scope van je app — zijn dezelfde die onze fintechpagina volledig beschrijft.

Catalogusmechaniek, op marketplace-schaal

OneTwoDo is geen winkel, maar wel een doorbladerbare catalogus van aanbiedingen met foto's, zoeken, prijzen in meerdere valuta en een feed gefilterd op taal en locatie — ontworpen en opgeleverd in zeven weken. De mechaniek van "een grote verzameling dingen mooi tonen op een middenklassetelefoon" gaat één-op-één mee.

Wat e-commerce-apps werkelijk vragen

Vijf zorgen komen in elke retailbouw terug. Zo pakken we ze aan.

Een catalogus groter dan het toestel

De catalogus leeft op de server; de app houdt er een bewegend venster op. Die zin verbergt het meeste engineeringwerk: gepagineerde queries die de scrollpositie stabiel houden, zoeken dat typefouten verdraagt en in milliseconden antwoordt, afbeeldingen op maat en gecachet zodat een productraster geen databundel opeet, en een productpagina die meteen rendert vanuit gecachte lijstdata terwijl de details erachter laden. Doe je dit verkeerd, dan voelt de app overal traag terwijl elk afzonderlijk verzoek er prima uitziet.

Een afrekenproces dat falen als hoofdpad behandelt

Betalingen falen — kaarten worden geweigerd, 3-D Secure-verificaties verlopen, de app gaat halverwege een betaling naar de achtergrond, het netwerk valt weg tussen de bevestiging van de aanbieder en het moment dat je backend ervan hoort. Een afrekenproces wordt om die gevallen heen ontworpen, niet om het gelukkige pad: idempotente orderaanmaak zodat een nieuwe poging nooit twee keer kan afschrijven, betaalstatus die bij de server ligt en door de client alleen wordt getoond, en voor elke uitkomst een duidelijk antwoord op het scherm. "Betalingen die bij de aanbieder slagen maar je backend niet bereiken" is de bugklasse die echt geld kost, en die wordt in de architectuurfase weggenomen.

Native betaalschermen, native gedaan

Apple Pay en Google Pay converteren op mobiel aanzienlijk beter dan getypte kaartformulieren, en beide worden vanuit Flutter bereikt via platform channels op de eigen SDK van elk platform. Wij zetten ze naast de kaartstroom van de aanbieder, niet in plaats daarvan, en we houden ruwe kaartgegevens binnen de SDK van de aanbieder zodat je PCI-scope zo klein blijft als je product toelaat.

Prijzen zijn geld, en geld is geen float

Elke prijs, korting, belastingregel en elk totaal is een heel getal in de kleinste eenheid of een decimaal type — nooit drijvende komma, waar 0.1 + 0.2 niet gelijk is aan 0.3 en een winkelwagentotaal kan afwijken van de som van zijn regels. Afrondregels zijn expliciet en getest op elke grens waar geld wordt getoond, verstuurd of opgeslagen. De lange versie staat in Waarom 0,1 + 0,2 ≠ 0,3.

De winkelregels die retailteams te laat ontdekken

Beide winkels rekenen commissie over digitale goederen maar niet over fysieke — fysieke producten via je eigen betaaldienstverlener verkopen is prima, en digitale extra's mengen in een retailapp is waar de beoordelingsproblemen beginnen. Apples richtlijn 4.2.6 is de andere valkuil: een vloot dunne, vrijwel identieke merkapps is precies wat die richtlijn moet afwijzen, en een white-label-platform zo ontwerpen dat het erdoorheen komt is een specialiteit van ons in plaats van een verrassing in week twintig. Accountverwijdering, gegevensveiligheidsverklaringen en beoordelingstermijnen worden als fase begroot, net als op elke pagina van deze site.

Waarom Flutter voor e-commerce

EisHoe Flutter dat aanpakt
Beide winkels, één budgetEén codebase, ongeveer 30–40% minder dan twee native winkels
Een merkzuivere UIFlutter tekent elke pixel, dus het designsysteem is van jou en niet van het platform
Snelle productrasters op goedkope telefoonsNative gecompileerd renderen houdt 60 fps waar shoppers werkelijk zitten — middenklasse Android
Seizoensgebonden iteratiesnelheidHot reload in minder dan een seconde; een promotiescherm staat er in dagen, niet in releasecycli
Meer dan één winkelDezelfde codebase schaalt van één merk naar een vloot — zie het white-label-platform

Waar native nog steeds wint: is je winkel in wezen een schil om de mogelijkheid van één platform — een ervaring die om App Clips draait, een diepe Wallet-koppeling als het product zelf — 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, architectuur, bouw, indienen bij de winkels. Ons ontwikkelproces beschrijft hoe dat er week na week uitziet.

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 e-commerce-app kost

Een winkel — catalogus en zoeken, winkelwagen en afrekenen, koppeling met een betaalgateway, ordertracking, reviews — is een eigen niveau op de pagina Flutter-appontwikkeling: € 40-72K, verspreid over vier tot zes maanden. Een platform met meerdere verkopers, een vloot merkapps of diepe ERP- en voorraadkoppelingen is enterprisewerk, vanaf vanaf € 72K.

Dit zijn dezelfde gepubliceerde niveaus als in de prijstabel van de pijler — dezelfde sleutels renderen beide, dus de twee kunnen niet uiteenlopen. Wat een retailbedrag daarbinnen beweegt: het aantal betaalmethoden en markten, hoeveel van de catalogusmachinerie je backend al levert, en of "één app" eigenlijk een vloot is.

Veelgestelde vragen

Veelgestelde vragen van teams die retail- en e-commerceproducten op Flutter bouwen.

Ja. Flutter tekent zijn eigen UI, dus een productraster, een promotiescherm of een eigen afrekenstroom ziet er op iOS en Android identiek uit en gedraagt zich ook zo, vanuit één codebase, doorgaans tegen 30 tot 40 procent minder dan twee native winkels bouwen. Het compileert naar native code, wat het scrollen soepel houdt op de middenklasse Android-toestellen waar veel retailverkeer werkelijk plaatsvindt. De platformspecifieke delen — de betaalschermen van Apple Pay en Google Pay, sommige SDK's van betaaldienstverleners — worden bereikt via platform channels, wat routinematig maar echt engineeringwerk is.
Ons gepubliceerde e-commerce-niveau dekt catalogus en zoeken, winkelwagen en afrekenen, koppeling met een betaalgateway, ordertracking, reviews en voorraadbeheer, verspreid over vier tot zes maanden — de exacte bandbreedte staat op deze pagina en op de pagina over Flutter-appontwikkeling in plaats van achter een verkoopgesprek. Platforms met meerdere verkopers en vloten merkapps worden als enterprisewerk geprijsd. Wat het bedrag beweegt is eerst het aantal betaalmethoden en markten, en daarna hoeveel catalogusmachinerie je backend al levert.
Ja, via platform channels op de eigen betaal-SDK van elk platform, gepresenteerd als het native betaalscherm dat gebruikers herkennen. Native betaalschermen converteren op mobiel meetbaar beter dan getypte kaartformulieren, dus we zetten ze naast de kaartstroom van de aanbieder, niet in plaats daarvan. Ruwe kaartinvoer blijft binnen de SDK van de betaaldienstverlener, wat je app buiten de PCI-scope houdt waar de aanbieder dat toelaat.
Ja, met de juiste architectuur: de catalogus leeft op de server en de app houdt er een gepagineerd venster op, met zoeken op de backend, afbeeldingen per scherm op maat en gecachet, en productpagina's die meteen renderen vanuit gecachte lijstdata terwijl de details erachter laden. De faalwijze is niet Flutter — het is een catalogus van honderdduizend artikelen behandelen als een lijst om op te halen. Wij hebben de bladermechaniek op marketplace-schaal opgeleverd, met prijzen in meerdere valuta en op locatie gefilterde feeds.
Niet altijd, en we zeggen het wanneer een goed gebouwde mobiele webervaring het eerlijke antwoord is. Een app verdient zijn budget terug via het retentieoppervlak dat een website niet heeft: pushmeldingen voor aanbiedingen en orderupdates, een icoon op het startscherm, native betaalschermen en loyaliteitsmechaniek die terugkomen beloont. Komt het grootste deel van je omzet van terugkerende klanten, dan is die businesscase meestal sterk; is het eenmalig zoekverkeer, investeer dan eerst in het web — dat bouwen we ook.
Ja — dat is onze meest directe referentie in commerce. Eén Flutter-codebase die we bouwden produceert meer dan vijftien volledig gebrande consumentenapps plus een merchantapp, met een beheerpaneel dat een nieuw merk lanceert zonder engineeringwerk. De winkelbeleidsvalkuil is Apple-richtlijn 4.2.6, die bestaat om vloten vrijwel identieke apps af te wijzen, en een white-label-platform moet vanaf het begin worden ontworpen om erdoorheen te komen. De volledige architectuur staat uitgeschreven op onze white-label-dienstpagina en in de bijbehorende engineeringpost.

Lees de kostenuiteenzetting in Wat een Flutter-app kost in 2026, bekijk hoe de vloot van het loyaliteitsplatform is gebouwd, of begin bij de pijler Flutter-appontwikkeling.