Kort samengevat. Elke bureausite zegt dezelfde drie dingen — senior team, bewezen proces, kwaliteit voorop — dus als filter zijn de woorden waardeloos. Wat wél werkt is verificatie: opgeleverde apps die je kunt installeren, engineeringdenken dat je kunt lezen, prijzen die vóór het verkoopgesprek zijn gepubliceerd, en referenties die je werkelijk belt. Dit stuk is de checklist die we zouden gebruiken als wij de kopers waren, en ja — we zijn een Flutter-bureau, dus aan het eind laten we hem op onszelf los en laten we zien waar je onze claims kunt controleren.

Waarom de gebruikelijke zoekroute misleidt

Zoek op "beste Flutter-ontwikkelbureau" en je vindt lijstjes en gidsen. Beide zijn nuttig en beide moeten worden ontcijferd. Veel lijstjes zijn betaald of affiliategedreven — een vermelding is marketing, geen verdienste. Gidsen als Clutch zijn nuttiger, omdat geverifieerde klantreviews in grote aantallen moeilijk te vervalsen zijn, maar lees de reviews en niet de badges: één gedetailleerde review die een echt project beschrijft vertelt je meer dan een dozijn vijfsterrenbeoordelingen van elk twee zinnen.

Geen van beide vervangt de twintig minuten directe verificatie hieronder. Elk criterium hier is vanaf je bureau te controleren voordat je ook maar een gesprek boekt.

Zes dingen om te verifiëren, niet om naar te vragen

1. Opgeleverde Flutter-apps die je kunt vasthouden

Geen screenshots — winkelvermeldingen. Open het portfolio, zoek de App Store- en Google Play-links, installeer twee apps en gebruik ze tien minuten. Scroll snel, draai het scherm, ga offline, kom terug. Een team dat verzorgd productie-Flutter uitlevert kan dat niet verbergen, en een team dat dat nooit heeft gedaan kan het niet veinzen. Wees wantrouwig bij een portfolio dat louter mockups en geen links bevat; heb begrip voor NDA-werk, maar verwacht ten minste enig benoemd, installeerbaar bewijs.

2. Engineeringdenken in het openbaar

Een bureau dat werkelijk met een realtime feed of een betaalstroom heeft geworsteld kan er drie concrete pagina's over schrijven; een dat dat niet heeft gedaan, schrijft "wij leveren schaalbare innovatieve oplossingen". Lees het blog. Zoek naar het concrete: benoemde afwegingen, getallen, dingen die misgingen. Open source is hetzelfde signaal, maar sterker — pakketten op pub.dev met echte gebruikers betekenen dat de code van het team publieke toetsing overleeft, en je kunt hem zelf lezen voordat je voor meer ervan betaalt.

3. Wie je app werkelijk gaat bouwen

De mensen in het verkoopgesprek en de mensen in je repo zijn vaak verschillende mensen. Vraag om namen en profielen van de engineers die aan jouw project worden toegewezen, controleer of teampagina's echte mensen met een verifieerbare staat van dienst tonen, en beschouw een weigering als een antwoord. Senioriteit doet er in Flutter meer toe dan de jonge vijver doet vermoeden: het framework is makkelijk om mee te beginnen en onverbiddelijk aan de randen van productie — widget-herbouw afbakenen, platform channels, winkelreview — waar een senior littekens heeft en een junior tutorials.

4. Prijzen en planningen die ze op schrift willen toezeggen

Een bureau dat bandbreedtes publiceert heeft besloten dat zijn getallen een vergelijking overleven; een dat pas na een verkenningsgesprek wil offreren houdt ruimte om de offerte op de klant af te stemmen. Dezelfde logica voor de kalender: "Hoe lang duurt een ?" verdient een concrete bandbreedte met voorwaarden, geen "dat hangt ervan af". Het hangt er altijd van af — professionals vertellen je waarvan, en hun voorwaarden leren je hoe ze denken.

5. Hoe een week met ze samenwerken eruitziet

Demo's op een vast ritme, een kanaal waarin je dagelijks voortgang ziet, en eerlijk rapporteren wanneer iets uitloopt — stel elke referentie bovenal één vraag: "Toen er iets misging, hoe kwam je erachter?" Ontdekte de klant de problemen zelf, loop dan weg. Trok het bureau als eerste aan de bel, met een plan erbij, dan is dat de leverancier die je wilt — en geen enkel offertedeck onthult het.

6. Wat er na de lancering gebeurt

Uitleveren ligt halverwege de kosten van een app, niet aan het einde — onderhoud heeft zijn eigen economie. Verifieer dat er een echt aanbod voor na de lancering is: monitoring, updates bij gewijzigd winkelbeleid, een benoemd aanspreekpunt. En controleer het eigenaarschap van de code in het conceptcontract, niet in het gesprek: jouw repository vanaf dag één, jouw winkels, jouw accounts. Elke wrijving op dit punt is een generale repetitie voor een gijzelingsonderhandeling.

Vijf rode vlaggen die het gesprek beëindigen

  1. Certificeringen als verkoopargument. "HIPAA-gecertificeerde developers" is een teken aan de wand — zo'n HIPAA-certificering bestaat niet, en een bureau dat met badges opent gokt erop dat jij dat niet weet. Compliance-geletterde teams beschrijven in plaats daarvan hoe ze bouwen.
  2. Op alles ja zeggen. Geen weerwerk op scope, planning of haalbaarheid tijdens het verkooptraject betekent dat het weerwerk ná de aanbetaling komt, als meerwerk.
  3. Een offerte zonder vragen. Wie je app prijst zonder scope, koppelingen en de onzichtbare 40% — inlogstromen, accountverwijdering, indienen bij de winkels — uit te vragen, noemt een getal dat bedoeld is om een relatie te beginnen, niet om een project af te maken.
  4. Geen engineers aan tafel. Krijg je vóór de verkoop geen technisch iemand in het gesprek, dan koop je van een verkooplaag die je product via een ticketwachtrij zal doorvertalen.
  5. Een portfolio zonder datums of winkellinks. Ongedateerd werk kan tien jaar oud zijn; werk zonder link kan van iedereen zijn.

Tien vragen voor het shortlistgesprek

  1. Welke van jullie opgeleverde Flutter-apps lijkt het meest op de onze — en mogen we met die klant spreken?
  2. Wie gaat er precies aan ons project werken, en waar werken ze verder aan?
  3. Wat zouden jullie uit onze scope schrappen, en waarom?
  4. Wat is jullie geschatte bandbreedte voor onze MVP, en wat beweegt die omhoog of omlaag?
  5. Hoe pakken jullie een betaalstroom / realtime functie / offline synchronisatie zoals de onze aan? (Kies je moeilijkste functie; luister of je concrete details hoort.)
  6. Hoe ziet een normale week er voor ons uit — demo's, kanalen, rapportage?
  7. Vertel over een project dat misging en wat jullie deden.
  8. Wat doen jullie niet, en waar zouden jullie ons in plaats daarvan naartoe sturen?
  9. Wat kost ondersteuning na de lancering en wat dekt die?
  10. Wanneer kunnen we de repository zien, en wiens naam staat erop? (Het juiste antwoord: de jouwe, vanaf dag één.)

Vraag 8 is de stille moordenaar. Een bureau zonder eerlijk antwoord op "wat doen jullie niet" heeft nooit nagedacht over waar het werkelijk goed in is.

Offertes vergelijken zonder jezelf voor de gek te houden

Offertes voor "dezelfde app" verschillen legitiem 3–5× — vooral omdat ze niet voor dezelfde app zijn. Normaliseer de scope voordat je getallen vergelijkt: welke functies, welke platforms, wiens backend, wiens ontwerp, welk testwerk, welk indieningswerk voor de winkels, welke periode na de lancering. Een gestructureerde uitsplitsing van wat de kosten van Flutter werkelijk bepaalt maakt die normalisatie behapbaar. Schrap daarna het goedkoopste bod, tenzij je kunt uitleggen waarom het goedkoop is — de gebruikelijke antwoorden zijn juniors, een offshorevoordeel dat verdampt in communicatieoverhead, of scope die de onzichtbare 40% stilletjes uitsluit. Goedkope engineering die herbouwd moet worden is de duurste soort; twee keer betalen is de standaarduitkomst van alleen op prijs kopen.

Geografie, nu we het er toch over hebben: nearshore- en offshoreteams kunnen uitstekend zijn — de variabele die uitkomsten voorspelt is niet de landkaart, maar de tijdzoneoverlap met jouw werkdag en de senioriteit van de mensen die werkelijk code committen. Eis drie of meer uur overlap en benoemde seniors, en de locatievraag beantwoordt zichzelf grotendeels.

Dezelfde checklist, losgelaten op ons

We zijn Nerdy Production, een Flutter-bureau, en het zou vreemd zijn om een doorlichtingsgids te publiceren en onszelf ervan uit te zonderen. Dus, regel voor regel: ons opgeleverde werk staat in het portfolio met winkellinks waar NDA's het toelaten — installeer ExtraETF of Jepta en beoordeel de scrollprestaties zelf. Het engineeringdenken staat op dit blog en in opensourcepakketten op pub.dev die je vanavond kunt lezen. De mensen staan op de teampagina, en degene in jouw gesprek is een engineer, meestal degene die de architectuur van je bouw zal bepalen. Prijzen en planningen zijn gepubliceerd, met de voorwaarden die ze bewegen. Voor referenties: vraag ernaar — we brengen je in contact met benoemde klanten, dezelfde die op deze site worden geciteerd.

En vraag 8, in het openbaar beantwoord: we doen geen native-only bouwtrajecten, we praten klanten migraties uit het hoofd die hun product niet nodig heeft, en wanneer Kotlin Multiplatform of Expo beter bij jouw team past, zeggen we dat in de vergelijkende stukken zelf.

Laat de checklist op ons los en op onze concurrenten. Verslaat iemand ons erop, huur die dan in.

Veelgestelde vragen

Gepubliceerde bureauniveaus voor een volledige bouw lopen doorgaans van rond de vijftienduizend dollar voor een slanke MVP tot negentigduizend en meer voor enterprisewerk — de onze staan openbaar op onze dienstenpagina's, van MVP tot en met e-commerceniveaus, juist zodat ze te vergelijken zijn. Uurmodellen voor senior engineers die in jouw team meedraaien landen gewoonlijk in de bandbreedte van vijftig tot honderd dollar, afhankelijk van geografie en senioriteit. Behandel elke offerte die zonder scopevragen wordt gegeven als een marketinggetal, en normaliseer de scope voordat je biedingen vergelijkt — offertes voor ogenschijnlijk dezelfde app verschillen legitiem een veelvoud, omdat de scopes verschillen.
Een sterke freelancer is de juiste keuze voor een kleine, goed afgebakende bouw met één harde vaardigheid als kern, en de verkeerde zodra je product ontwerp, backend en mobiel werk parallel nodig heeft, met continuïteitsverzekering erbij. Het echte product van een bureau is redundantie en proces: iemand reviewt de code, iemand kan halverwege het project overnemen, en de oplevering hangt niet af van de agenda of gezondheid van één persoon. De eerlijke kostenvergelijking gaat niet over dagtarieven, maar over wat een stilstand van drie weken in maand vier je lancering kost.
Installeer de apps. Echte portfoliovermeldingen linken naar App Store- en Google Play-vermeldingen; open er twee, gebruik ze tien minuten, en bekijk ondertussen de winkelreviews en de updategeschiedenis — een vermelding die sinds 2023 verlaten is vertelt zijn eigen verhaal. Vraag bij NDA-werk wat het bureau specifiek bouwde en wat het erfde. Toets de naam van het bureau aan klantgetuigenissen met echte namen en rollen, en vraag om rechtstreeks met een van die klanten te spreken; een zelfverzekerd bureau behandelt dat verzoek als routine in plaats van als een belasting.
Soms, en de faalwijze is voorspelbaar genoeg om op te testen. Locatie schrijft geen slechte code — juniorteams, dunne reviewprocessen en nul tijdzoneoverlap doen dat, waar ze ook zitten. Uitstekende teams bestaan in elke geografie en elke tariefband; wat je moet verifiëren is dezelfde lijst als overal: benoemde senior engineers op jouw project, installeerbaar opgeleverd werk, en ten minste drie uur overlap met jouw werkdag. Wat goedkoop duur maakt is de herbouw — code die op productiekwaliteit moet worden herschreven kost meer dan hem één keer goed bouwen.
Een vaste prijs past bij een goed afgebakende eerste bouw: het bureau draagt het schattingsrisico, jij krijgt een toegezegd getal, en de discipline van de schraplijst opschrijven komt beide kanten ten goede — zo draaien wij MVP-trajecten. Nacalculatie past bij doorlopende evolutie na de lancering, of bij werkelijk verkennend werk waar scope vastleggen fictie zou zijn. De constructie om te weigeren is een vaste prijs met vage scope, die elk gesprek omzet in een meerwerkonderhandeling. Een capabel bureau vertelt je welk model bij jouw situatie past in plaats van standaard het model te kiezen dat henzelf uitkomt.
Ja, en het gebeurt vaker dan de industrie toegeeft — geërfde codebases zijn een betekenisvol deel van de instroom van serieuze bureaus. De mechaniek hangt af van twee dingen die je op dag één van het oorspronkelijke traject moet veiligstellen: repository-eigenaarschap op jouw naam en winkelaccounts onder jouw beheer. Een competente opvolger begint met een betaalde audit van de bestaande code in plaats van met een belofte, en het auditrapport is meteen je onderhandelingspositie. Soms is het oordeel twee weken fixes en geen herbouw — een overname hoort hoe dan ook met bewijs te beginnen.

Nu bureaus aan het shortlisten? Plan een gesprek van 30 minuten en neem deze checklist mee — we beantwoorden alle tien de vragen, ook de vragen die ons niet vleien.