Kort samengevat. "Mobiele kosten 40% omlaag" is het soort getal dat in verkooppresentaties van bureaus opduikt en zonder uitsplitsing vrijwel niets betekent. Dit stuk ís die uitsplitsing. We halen vier projecten uit ons portfolio — Arcana, YouMi, ExtraETF en Formtastic — en laten precies zien waar de kostenverlaging bij elk vandaan kwam. Een deel zat in de keuze van het framework. Een deel zat erin dat er niets herbouwd hoefde te worden. Niets ervan was toverij.

Wil je de kostenknoppen zonder de casestudy's, spring dan naar de vijf drijvers.

Waarom "40% goedkoper" meestal een leugen is

Vertelt een bureau je dat het de mobiele kosten van een klant met een rond percentage verlaagde, stel dan één vraag: 40% waarvan, gemeten waartegen?

  • 40% van het uurtarief is verplaatsen naar een goedkoper land, geen engineering.
  • 40% van de bezetting is mensen ontslaan, geen bouw optimaliseren.
  • 40% van de is echte engineeringwinst, want die stapelt zich op — elke gewonnen week is een week omzet, een week feedback, een week concurrentiepositie.
  • 40% van de over drie jaar is het zeldzaamst en het waardevolst, omdat daar de onderhoudsrekening in zit die niemand vooraf noemt.

De vier casestudy's hieronder zijn allemaal echt, allemaal uit ons portfolio, allemaal na te trekken. Ze illustreren verschillende kostenknoppen, en de besparingen komen van verschillende plekken. Geen ervan is "we hebben gewoon goedkopere engineers ingezet."

Casus 1 — ExtraETF: 40% kortere time to market

Project: ExtraETF voor Isarvest GmbH. Duur: 6 maanden. Stack: Flutter en Go.

ExtraETF is een financiële app voor analyse van ETF's en aandelen — realtime koersstromen, interactieve grafieken, pushmeldingen, OAuth, abonnementen in de app. Het soort app waarbij de verleiding groot is om twee native codebases te bouwen (Swift op iOS, Kotlin op Android), omdat financiële apps "native moeten aanvoelen."

Dat deden we niet. We bouwden hem één keer in Flutter en brachten hem in 6 maanden met gelijke functies naar beide winkels. De geschatte verkorting van de time to market ten opzichte van een parallelle native bouw was 40%.

Waar kwam die 40% werkelijk vandaan?

  • Eén mobiele codebase in plaats van twee. De meeste native trajecten draaien iOS en Android als parallelle sporen. Zelfs met de beste afstemming schrijf je bedrijfslogica dubbel, los je dezelfde bug twee keer op, en lever je functies op die op het ene platform werken en op het andere breken. Flutter haalt die overhead volledig weg.
  • Geen achterstand door platformafwijking. Levert iOS een functie eerst op, dan wachten Android-klanten. Heeft Android bijgetrokken, dan heeft iOS er twee bij. Die achterstand is een verborgen belasting — bij Flutter bestaat ze niet.
  • Grafiekwerk één keer gedaan. ExtraETF is grafiekzwaar. Native grafiekbibliotheken op iOS en Android zijn totaal verschillende beesten; hun uiterlijk en gedrag op elkaar afstemmen kost weken. Flutter tekent elke pixel zelf, dus de grafiekcode draait op beide platforms identiek.

Die 40% is geen marketingregel — het is wat er uit de rekensom valt zodra je ophoudt hetzelfde werk twee keer te betalen. De -service in Go voor live koersen is hier een zijnoot; die knop ging over backendkosten per verbinding op schaal, niet over mobiele kosten.

Kostenknop: één codebase over iOS en Android. Na te trekken, herhaalbaar, geen eenmalige truc.

Casus 2 — Formtastic: twee native apps samenvoegen tot één

Project: Formtastic voor Formtasic GmbH. Duur: 1 jaar (volledige platformevolutie). Stack: Flutter, Nuxt, Django en Go.

Formtastic is de andere vorm van kostenverlaging. Ze hadden al twee native mobiele apps in productie — een voor iOS, een voor Android — en de kosten zaten niet in het bouwen van mobiel, maar in het onderhouden ervan. Twee codebases, twee teams, twee releasecycli, twee testrondes per functie.

We migreerden beide apps naar één Flutter-codebase. De kostenverlaging op mobiel was hier geen percentage van een offerte — het was een structurele verschuiving in wat het maand na maand kostte om het product te draaien.

Wat er concreet veranderde:

  • Releasecycli gelijkgetrokken. Ervoor: iOS kwam uit, Android een week later als het team geluk had. Erna: één build, één release, beide winkels tegelijk.
  • Gelijke functies hielden op een coördinatieprobleem te zijn. Een nieuwe functie wordt één keer geschreven. Randgevallen worden één keer afgehandeld. Het Slack-bericht "we zijn vergeten dit aan Android toe te voegen" verdween.
  • De onderhoudspost kromp. Twee native apps vragen elk jaar twee upgradetrajecten — nieuwe iOS-versie, nieuwe Android-versie, nieuwe SDK-eisen, nieuw App Store-beleid, nieuw Play Store-beleid. Flutter kost nog steeds upgradewerk, maar ruwweg de helft.

Parallel verhuisde de webfront-end van Django-templates naar een aparte Nuxt-app, en gingen enkele drukke services van Django naar Go. Beide besluiten hadden hun eigen rendement, maar het samenvoegen van mobiel was de grootste afzonderlijke post op de kostenverlagingsrekening.

Kostenknop: oppervlak verkleinen. Twee codebases → één. Twee teams → één. De meeste kostenbesparingstrajecten die we zien maken de fout hetzelfde werk goedkoper te willen doen. Formtastic deed mínder werk, bij gelijke kwaliteit.

Casus 3 — YouMi: de prijs van geen Flutter-expertise hebben

Project: YouMi voor YouMi LLC. Duur: 2 weken. Stack: Flutter.

YouMi is de casus die oprichters het liefst negeren, want hij gaat over de kosten van niet meteen het juiste team hebben.

YouMi had al een Flutter-app in productie. Die ging stuk. Gebruikers raakten midden in een sessie met hun psycholoog de verbinding kwijt. Chatberichten kwamen niet aan. Navigeren tussen schermen was onvoorspelbaar. Het product werkte zolang er niets misging, wat in een echte productieapp nooit het geval is.

De oorzaken waren twee weinig glamoureuze dingen: een WebSocket-laag zonder deugdelijk beheer van de levenscyclus, en een navigatiestack met geheugenlekken. Beide zijn problemen die een Flutter-engineer die een paar productieapps heeft opgeleverd op de automatische piloot oplost. Beide zijn problemen waar een Flutter-engineer die dat niet heeft gedaan maandenlang mee worstelt.

Wij namen de codebase over, herstelden beide onderdelen, en leverden in twee weken een stabiele build op.

Zo ziet het kostenplaatje eruit: het alternatief was niet "bouw het goedkoper". Het alternatief was "blijf gebruikers verliezen tot het product faalt." Reken die kosten uit — het verloop, de terugbetalingen, de merkschade, het moreel van de oprichter — en die opdracht van twee weken is geen post in de projectbegroting. Het is dat het project überhaupt overleeft.

Dit is de wig voor teamuitbreiding als dienst: één kleine, meedraaiende engineer met de juiste patroonherkenning voorkomt het soort productfalen in slow motion dat in geen enkele offerte een regel heeft.

Kostenknop: patroonherkenning. De goedkoopste versie van elk mobiel project is de versie die na een half jaar geen reddingsactie nodig heeft.

Casus 4 — Arcana: snelheid naar prototype op een lastig probleem

Project: Arcana voor een klant met een AI-tarotproduct. Duur: 3 weken. Stack: Flutter.

Arcana laat zien hoe snelheid naar een prototype eruitziet wanneer het technische probleem werkelijk lastig is. De klant bezat de AI-backend. Ze hadden een chatclient nodig die:

  • AI-antwoorden in realtime kon streamen via .
  • Markdown-opmaak stapsgewijs kon renderen terwijl tokens binnenkwamen — vet, cursief, koppen, lijsten — zonder geflikker of haperende lay-out.
  • Soepel op 60 fps kon blijven op een eenvoudig Android-toestel terwijl je door 5.000 berichten scrolt.

Dat is geen CRUD-app. Dat is een eigen renderengine geschroefd op een eigen netwerklaag.

Wij leverden hem in 3 weken op.

De kostenknop is hier subtiel. We bespaarden de klant geen geld door minder code te schrijven — dit in 3 weken bouwen vroeg meer zorgvuldige engineering dan een doorsnee chatapp in 3 maanden bouwen. We bespaarden ze geld door de planning in te klappen. Elke week dat het AI-product niet voor gebruikers stond was een week aanloop voor de concurrent, vragen van investeerders, en onzekerheid in het team. Een bouw van 3 weken liet hen de producthypothese toetsen voordat de rekensom over de resterende middelen lelijk werd.

Snelheid naar prototype is een kostenknop die in geen enkele uurberekening opduikt. Ze duikt op in welke besluiten je mag nemen, en hoeveel je er mag nemen voordat het geld op is.

Kostenknop: tijd. Specifiek: besluitvormingstijd die je terugkoopt door snel op te leveren op een lastig probleem.

De vijf drijvers achter elke kostenverlaging

Over deze vier projecten heen kwamen de kostenverlagingen van dezelfde vijf herhaalbare drijvers. Geen ervan is exotisch. Ze vragen allemaal om een bureau dat eerlijk durft te zijn over de scope.

1. Eén codebase, geen twee

De goedkoopste cross-platform bouw is de bouw die werkelijk vanuit één bron op beide platforms draait — de premisse van ons werk aan Flutter-appontwikkeling. De aanspraak van Flutter daarop is voor interfacezware producten sterker dan die van React Native (waarom, verkenden we in Flutter tegenover React Native in 2026), maar het grotere punt is dat elke echte cross-platform stack twee parallelle native trajecten op kosten verslaat. De meeste oprichters onderschatten hoeveel van een native bouw dubbel werk is.

2. Oppervlak verkleinen, geen hoeken afsnijden

Het patroon van Formtastic. De goedkoopste functie is de functie die je niet op twee plekken hoeft te onderhouden. De goedkoopste backend is die met minder services, niet meer. Kosten verlagen door vereenvoudiging stapelt zich op; kosten verlagen door testen te schrappen niet.

3. Patroonherkenning boven uren

Het patroon van YouMi. Een senior Flutter-engineer op een bekende probleemsoort is dramatisch sneller dan twee medior engineers op hetzelfde probleem. Het uurtarief is hoger; de totale kosten zijn lager. Dat is de hele premisse van teamuitbreiding — expertise binnenhalen die de dure faalwijzen voorkomt, niet alleen handen die tickets afwerken.

4. Snelheid naar prototype op nieuwe problemen

Het patroon van Arcana. Is het technische probleem voor het team ongekend, dan is de kostenknop niet de bouw verkleinen — het is de tijd verkleinen tussen "we hebben een hypothese" en "we hebben data". Drie weken tegenover drie maanden is geen besparing van 75% op engineering; het is het verschil tussen een product dat uitkomt en een product waarvan het geld op raakt.

5. Lager onderhoud op de lange termijn

De verborgen post. Elke keuze voor een mobiel framework is een verbintenis van 3 tot 5 jaar. De upgrade- en onderhoudsrekening over dat venster is vaak groter dan de eerste bouw. Over de kostenuitsplitsing per niveau schreven we in Wat een Flutter-app kost in 2026, maar kort gezegd: kies de stack met de laagste toekomstige kosten, niet met de laagste kosten vandaag.

Wat dit voor jouw project betekent

Ben je een oprichter die dit leest met een mobiel project in gedachten, dan is de vraag niet "hoe krijg ik er 40% af?" De vraag is welke van de vijf knoppen op jouw situatie van toepassing is:

  • Begin je vanaf nul en plan je twee native trajecten — knop 1.
  • Betaal je al voor het onderhoud van twee native apps — knop 2.
  • Gaat je bestaande app stuk en heb je geen senior Flutter-engineer in dienst — knop 3.
  • Race je tegen een concurrent of tegen de klok van je resterende middelen — knop 4.
  • Bouw je iets dat je de komende 3 jaar of langer wilt draaien — knop 5.

De meeste projecten hebben er een of twee. Enkele hebben er drie. De casussen hierboven leunden elk zwaar op een andere, en daarom zagen de kostenverlagingen er van buiten anders uit terwijl de onderliggende mechaniek dezelfde was.

Raam je eigen project

De betrouwbaarste manier om een echt getal voor jouw specifieke project te krijgen is de traagste: een gesprek van 30 minuten waarin we de vijf drijvers naast jouw werkelijke situatie leggen. Geen presentatie, geen verkooppraat — alleen het gesprek dat een eerlijke offerte oplevert.

Is dat nuttig, plan dan een verkennend gesprek. Wil je eerst het model lezen, dan is Wat een Flutter-app kost in 2026 het bijbehorende stuk dat doorloopt hoe scope, backend, koppelingen, ontwerp en compliance samen tot het eindbedrag optellen. En begon je product als Telegram-bot, dan loopt hem in zes weken als app uitbrengen precies die migratie door — planning, kosten, en hoe je je gebruikers niet kwijtraakt.

En heb je al een Flutter-app in het wild die zich misdraagt — zoals YouMi — dan is dat het gesprek dat we het liefst als eerste voeren. Twee weken senior engineering op het juiste moment is bijna altijd goedkoper dan nog twee kwartalen falen in slow motion.