In 2024 liep gemiddeld 27% van alle grote rijks-ICT-projecten over budget. Slechts 8 van de 31 afgeronde projecten werden op tijd opgeleverd. De oorzaken zijn bij kleinere app-projecten vrijwel identiek.
Oorzaak 1
De meeste app-projecten beginnen met een idee dat helder klinkt. "We willen een app waarmee onze klanten bestellingen kunnen plaatsen." Prima. Maar ergens tussen dat gesprek en de eerste lijn code verschijnen nieuwe wensen: een beheerpaneel voor de backoffice, pushnotificaties, een koppeling met het plannings- of boekhoudsysteem, en misschien ook nog een webversie.
Elk afzonderlijk verzoek lijkt redelijk. Samen verdubbelen ze de omvang van het project, en daarmee de kosten en de doorlooptijd. Dit is een van de meest voorkomende oorzaken van projecten die uitlopen.
Het begint bijna altijd met onduidelijke afspraken aan het begin: wat zit er wel in, en wat niet? Een goed bureau legt dat vast per fase, met een eigen budget en oplevering. Zo weet je voor elke fase wat je krijgt, en kun je per fase beslissen of je verdergaat.
Duidelijke afspraken lossen het probleem maar half op. Het andere deel is voortgangscontrole. Wanneer scope en verwachting niet goed op elkaar zijn afgestemd, wordt dat bij te weinig contactmomenten pas laat ontdekt.
Een werkwijze die dit voorkomt: elke twee weken laat je zien wat er gebouwd is: niet als statusrapport, maar door het werkende product te demonstreren. Ziet het eruit zoals de klant verwachtte? Zo kun je bijtijds bijsturen, in plaats van na zes maanden bouwen te ontdekken dat de helft anders moet.
Oorzaak 2
Een offerte zegt niets over wie het werk daadwerkelijk uitvoert. Sommige bureaus presenteren een team van ervaren developers en zetten vervolgens stagiaires in als volwaardige krachten, met onvoldoende begeleiding.
Hoe herken je dit? Als een project structureel uitloopt zonder aanwijsbare reden: niet door onduidelijke scope, niet door externe koppelingen, maar gewoon steeds "iets meer tijd nodig". Dat is een alarmsignaal. Ervaren developers schatten beter in wat iets kost en vragen vaker om verduidelijking vooraf.
Een tweede signaal: als je vraagt of er geautomatiseerde tests worden geschreven en het antwoord vaag blijft. Zulke tests controleren automatisch of bestaande functies nog werken nadat er iets is aangepast. Bureaus die hier niet in investeren, leveren sneller, maar het achterstallig onderhoud dat dat oplevert betaal je later terug in bugs, vertraging en duur herstelwerk.
Hetzelfde geldt voor codestructuur: zonder geautomatiseerde stijlcontrole groeit de code al snel uit tot wat developers "spaghetti code" noemen: code die werkt, maar die niemand meer durft aan te raken uit angst voor onverwachte gevolgen. Als je later een ander bureau inschakelt om zo'n project over te nemen, kan dat flink duurder uitvallen dan een nieuw project.
Oorzaak 3
Maatwerk software bouwen is in het begin duurder dan kant-en-klare abonnementssoftware gebruiken. Dat klopt. Maar de vergelijking stopt daar niet.
Bij abonnementssoftware lopen de kosten in de loop van de jaren op. Ze zijn vaak afhankelijk van gebruik: aantal gebruikers, hoeveelheid data, het aantal acties dat de software uitvoert. Wat in jaar één een overzichtelijk bedrag is, kan in jaar vier een significante kostenpost zijn geworden.
Maatwerk heeft die afhankelijkheid niet. Je betaalt eenmalig voor de bouw, en daarna alleen voor hosting en onderhoud. De software schaalt zonder dat de rekening meegroeit. Wij bouwen uitsluitend maatwerk, zonder licentieafhankelijkheden.
Als een bureau de app voor jou bouwt, is die app niet automatisch van jou. Dat hangt af van wat er in het contract staat. Veel bureaus leggen hier niets over vast, of formuleren het vaag.
Stel: je leverancier gaat failliet, wordt overgenomen door een partij met andere tarieven, of stopt simpelweg met de dienstverlening. De code is dan geen eigendom van jou, maar van de leverancier. Bij een overname gaat dat eigendom mee naar de nieuwe partij. Bij een faillissement valt het in de boedel. In beide gevallen heb je geen garantie dat je de app nog kunt doorontwikkelen.
Dit risico is niet hypothetisch. Wij krijgen regelmatig ondernemers aan de telefoon waarvan de leverancier failliet is gegaan: de app staat nog in de App Store, maar op het account van het bureau. De bronbestanden zijn nergens meer te vinden. Ze staan met lege handen, voor software waar ze tienduizenden euro's voor hebben betaald.
Wij leggen in elk contract vast dat de broncode na oplevering volledig eigendom is van de klant.
Oorzaak 4
Een onderschatte vertrager: de klant die geen beslissingen neemt.
App-ontwikkeling vraagt voortdurend om keuzes. Welke functie heeft prioriteit? Hoe werkt dit scherm precies? Wat is de tekst op deze knop? Als die keuzes niet snel worden gemaakt, wacht het bouwteam. En dat wachten kost geld, ook als er geen uur wordt gewerkt.
Een bureau dat hierover niets zegt, doet je geen plezier. Een goed bureau maakt de verwachting vooraf duidelijk: voor elke bouwperiode is er een lijst van beslissingen die vóór de start genomen moeten zijn. Komen die niet op tijd, dan schuift het werk op.
Wat wordt er per fase opgeleverd?
Een offerte zonder fasedefinitie is een vrijblijvend prijsplaatje. Vraag wat je krijgt en wat het kost per fase.
Wie schrijft de code?
Medewerkers in vaste dienst, freelancers of stagiaires? En wie controleert het werk?
Worden er geautomatiseerde tests geschreven?
Tests zijn de basis voor betrouwbare doorontwikkeling. Een vaag antwoord is een slecht teken.
Wie is eigenaar van de bronbestanden?
Staat in het contract dat de code na oplevering volledig van jou is? Zo niet: vraag waarom niet.
Wat zijn de kosten bij groei?
Niet alleen nu, maar ook als het aantal gebruikers of de hoeveelheid data toeneemt.
Eerder werk
Veelgestelde vragen
Hoe wij het aanpakken
We werken in fasen met een vaste oplevering per fase, schrijven geautomatiseerde tests, en leggen in elk contract vast dat de bronbestanden na oplevering volledig eigendom zijn van de klant.
Wil je weten wat dit betekent voor jouw project? We leggen het graag uit in een kennismakingsgesprek, zonder verkoopverhaal, gewoon een eerlijk gesprek over wat jouw project vraagt.
Plan een vrijblijvend gesprek →We drinken graag een kop koffie met je. Vertel ons over jouw idee en wij denken eerlijk mee over wat er mogelijk is.
Plan een gesprek →
