Een schatting voor appontwikkeling is alleen nuttig als elke leverancier hetzelfde resultaat begroot. “Een iOS- en Android-app” benoemt platforms, maar geen scope. Bepaal eerst wat de eerste release moet aantonen en welke gebruikersflow daarvoor bewijs levert.
Gebruik de kostencalculator voor iOS- en Android-apps om een concrete beginscope vast te stellen. Een voorbeeld uit deze studio: een Flutter-MVP met één functie voor beide platforms kost €15.000; met productontwerp en kwaliteitscontrole van die functie komt het project op €18.000. Beide bedragen zijn exclusief btw. Dit is één afgebakend aanbod, geen branchegemiddelde.
Bepaal het werk voordat je prijzen vergelijkt
Geef elke leverancier dezelfde briefing. Beschrijf welk resultaat gebruikers nodig hebben, welk werk daarvoor nodig is en waaraan je kunt zien dat het klaar is. Neem op:
- De gebruikers, rollen en belangrijkste flows, plus een duidelijke lijst van wat buiten de eerste release valt.
- De vereisten voor iOS en Android, inclusief functies die platformspecifiek gedrag nodig hebben.
- Backend, datamigratie, integraties met derden en wie elke afhankelijkheid beheert.
- Verwachtingen voor ontwerp, toegankelijkheid, lokalisatie, privacy en beveiliging.
- Tests, acceptatiecriteria, verantwoordelijkheden voor de release, overdracht en wie open vragen beantwoordt.
De schatting verandert meestal door onzekerheid: een niet-gedocumenteerde integratie, inconsistente bestaande gegevens, late ontwerpbeslissingen, extra goedkeuringsrondes of een platformvereiste die niet in de briefing stond. Vraag leveranciers naar hun belangrijkste aannames, hoe ze die gaan toetsen en wat er gebeurt als een aanname niet klopt. Zie wat het bouwen van een MVP in 2026 kost voor bredere prijsranges en de factoren daarachter.
Vergelijk offertes voor gelijkwaardig werk
Leg elke offerte naast dezelfde scope. Vraag om schriftelijke antwoorden over deliverables en uitsluitingen, aannames en afhankelijkheden, wie het werk uitvoert, hoe voortgang en acceptatie worden geregeld en wat een wijziging betekent voor kosten en planning. Controleer of tests, releasevoorbereiding en overdracht zijn inbegrepen.
Een lager totaalbedrag kan betekenen dat meer risico rond scope of oplevering bij jou ligt. Vergelijk aannames en de procedure voor wijzigingen voordat je over het bedrag onderhandelt. Een vaste prijs en een overeenkomst op basis van uren en materiaal verdelen risico ook anders; lees hoe die contractvormen verschillen.
Maak van de offertes een besluit
Zet de voorstellen in dezelfde volgorde en maak elk verschil zichtbaar. Een beknopt vergelijkingsoverzicht behandelt:
- Resultaat en acceptatie. Benoem de inbegrepen gebruikersflows, platforms en integraties en beschrijf daarna hoe je aantoont dat elk onderdeel werkt. Een functienaam zoals “betalingen” is te ruim als acceptatiecriterium.
- Mensen en beschikbaarheid. Vermeld wie het werk uitvoert, wie technische beslissingen neemt, hoeveel tijd de senior lead aan het project besteedt en wie de overdracht of vakanties opvangt.
- Oplevering en afhankelijkheden. Toon de volgorde van mijlpalen, wat jouw team moet aanleveren en hoe vertraging bij appwinkelaccounts, API’s, testapparaten of goedkeuringen de planning beïnvloedt.
- Wijzigingen en nazorg. Beschrijf wat er gebeurt als een aanname verandert, welke ondersteuning na de release is inbegrepen en voor welke terugkerende diensten of nieuwe functies extra wordt betaald.
Ontbreekt er een onderdeel in een voorstel, vraag die leverancier dan om het apart te begroten of de uitsluiting expliciet te vermelden. Beschrijven de offertes nog steeds verschillende producten, stuur dan elke leverancier dezelfde herziene briefing en vraag om een nieuwe schatting. Een gemiddelde van onvergelijkbare bedragen verbergt juist het risico dat je probeert te begroten.
Houd ontwikkeling gescheiden van kosten na de lancering
De bouw omvat het ontwerpen, ontwikkelen, testen en overdragen van het afgesproken product. Begroot na de release doorlopende diensten zoals hosting, opslag, externe API’s, monitoring en appwinkelaccounts, en onderhoud zoals bugfixes, updates van afhankelijkheden en compatibiliteit met besturingssystemen. Sommige servicekosten variëren met het gebruik. Nieuwe functies zijn extra ontwikkelwerk, ook als hetzelfde team ze bouwt.
Leg duidelijk vast waar de release en ondersteuning ophouden. Het releasepakket van deze studio omvat één maand bugfixes, een QA-omgeving en overdracht van de projectrepository en documentatie aan jou. Spreek apart af hoe ondersteuning na die maand werkt en welke diensten je bedrijf rechtstreeks betaalt.
Leg eigendom en overdracht duidelijk vast
Je bedrijf hoort de broncoderepository, appwinkelaccounts en cloudaccounts te beheren. In de overeenkomst staat wie eigenaar is van maatwerkcode en ontwerp, welke licenties van derden gelden en welke praktische instructies nodig zijn voor builds, tests en releases. Een nieuwe engineer moet het werk kunnen voortzetten zonder privétoegang die alleen de leverancier heeft.
Bestaat de app al? Onderzoek die dan voordat je een herschrijving begroot
Bekijk de repository, huidige builds, afhankelijkheden, tests, releasepipeline, backendgrenzen en bekende productieproblemen voordat je besluit wat je vervangt. Een productaudit kan laten zien wat je moet behouden, repareren of herbouwen voordat je voor een migratie kiest.
Pas een afgebakende beginscope aan met de appkostencalculator en vergelijk daarna offertes op hetzelfde resultaat, doorlopende verantwoordelijkheden en eigendomsafspraken.