Software laten ontwikkelen: zo pak je het slim aan

Een directeur van een groeiend mkb-bedrijf merkt dat de huidige werkwijze begint te knellen. Medewerkers kopiëren gegevens tussen een CRM, boekhoudpakket en Excel, een klant wacht op een portaal en een losse programmeur bouwt ondertussen aan een eerste versie. De schermen werken, maar de koppeling met Exact faalt, documentatie ontbreekt en niemand weet wie na livegang verantwoordelijk blijft.

Dat is de realiteit achter software laten ontwikkelen. Het gaat niet om een verzameling functies, maar om een product dat dagelijks moet werken, veilig moet blijven en aangepast moet worden wanneer processen, gebruikers of externe API's veranderen. Nederlandse bedrijven zijn al sterk gedigitaliseerd. In 2022 had 97% internettoegang, beschikte 93% over een eigen website, gebruikte 53% CRM-software en 46% ERP-software, volgens het CBS-overzicht over ICT-gebruik bij bedrijven.

De twee grootste misvattingen zijn hardnekkig. Softwarebouw is geen eenmalige aankoop die uitsluitend per uur of functie wordt afgerekend, en de goedkoopste offerte is zelden de verstandigste keuze. De initiële bouw is slechts het begin van bezit, onderhoud, monitoring, beveiliging, integraties en doorontwikkeling. Over een langere periode kan de totale investering daardoor aanzienlijk hoger worden dan het oorspronkelijke bouwbudget.

Een systeem kan technisch gezien af zijn en toch zakelijk onbruikbaar blijken. Een ontwikkelaar levert bijvoorbeeld een klantportaal op dat gegevens toont, maar de synchronisatie met AFAS loopt vast zodra een veldnaam verandert. Zonder logging, foutafhandeling en duidelijke eigenaar van de API-sleutel ontdekt het bedrijf het probleem pas wanneer klanten gaan bellen.

Maatwerksoftware is daarom een levend product. De oplossing draait op hosting, gebruikt libraries en koppelt vaak met diensten van derden. Die omgeving verandert voortdurend. Een leverancier van een boekhoudpakket past endpoints aan, een beveiligingslek vraagt om een patch en gebruikers vragen om verbeteringen die tijdens de eerste bouw nog niet zichtbaar waren.

Praktische regel: begroot software vanaf het begin als een product met een bouwfase, een stabilisatiefase en een doorlopende beheerfase.

De Nederlandse sector heeft al vóór de huidige AI-golf een volwassen positie opgebouwd. In 2014 waren er circa 44.000 softwarebedrijven, met een omzet van 23,5 miljard euro. In de crisisjaren 2010 tot en met 2014 groeide de netto omzet met 4%, nam de werkgelegenheid met 3% toe tot ruim 164.000 mensen en verdubbelde de export naar 3,1 miljard euro, volgens Computable over de Nederlandse softwaresector.

Ook de productie is sterk lokaal verankerd. Een analyse van Dialogic stelde vast dat 92,1% van alle software in Nederland in Nederland wordt ontwikkeld. Dezelfde analyse kwam uit op 57.367 fte voor softwareontwikkeling, of 67.888 fte wanneer implementatie wordt meegerekend, zoals beschreven in het onderzoek naar de Nederlandse softwaresector.

Voor een opdrachtgever betekent dit een concrete keuze. Een partner moet niet alleen code kunnen schrijven, maar ook integraties beheren, beslissingen documenteren en beschikbaar blijven wanneer de eerste release al lang online staat. Wie alleen naar het uurtarief kijkt, vergelijkt een zichtbaar getal met onzichtbare risico's.

De keuze begint niet met een offerte, maar met het type samenwerking dat het project nodig heeft. Een eenmanszaak of zzp'er kan uitstekend passen bij een afgebakende interne tool, zeker wanneer de stack bekend is en de opdrachtgever zelf productkennis levert. Het risico zit in continuïteit. Bij ziekte, een andere opdracht of vertrek ontbreekt snel een tweede paar ogen.

Een gespecialiseerd Nederlands maatwerkbureau brengt meestal meerdere disciplines samen, zoals development, UX, testen en projectleiding. Een hybride consultancy voegt daar procesanalyse en strategisch advies aan toe. Dat is waardevol wanneer het bedrijf nog niet weet welke processen werkelijk geautomatiseerd moeten worden. Een nearshoreteam in Oost-Europa kan capaciteit toevoegen, maar vraagt strakke communicatie, duidelijke documentatie en iemand aan Nederlandse zijde die dagelijks prioriteiten bewaakt.

Gebruik voor een shortlist vier harde criteria:

• Technische diepte: vraag naar concrete ervaring met Laravel, .NET, React, Node.js of de stack die het project vereist. Een lange technologielijst zegt minder dan aantoonbare ervaring met de gekozen architectuur.
• Integratiekennis: laat voorbeelden zien van koppelingen met Exact, AFAS, SAP, CRM-systemen of webshops. Vraag vooral hoe logging, retries en foutmeldingen zijn ingericht.
• Transparant team: laat ieder teamlid benoemen wie analyseert, bouwt, test en aanspreekbaar blijft. Anonieme uren maken kennisoverdracht kwetsbaar.
• Vergelijkbare referenties: een generiek platformproject is geen bewijs dat een bureau een gereguleerd proces, complexe autorisaties of een legacy-migratie begrijpt.

De eerste gesprekken moeten praktisch zijn. Vraag welke aannames nog onzeker zijn, welke onderdelen in een aparte ontdekkingsfase horen en hoe de leverancier een mislukte integratie diagnosticeert. Vraag ook wie de Product Owner aan klantzijde nodig heeft en wat er gebeurt wanneer de scope tijdens de bouw verandert. Een praktische vragenlijst voor het kiezen van een softwarebureau helpt om gesprekken vergelijkbaar te maken.

Een vaste prijs past bij een scherp afgebakende fase met stabiele acceptatiecriteria. Time and materials past beter bij onderzoek, complexe integraties en producten waarvan de oplossing nog moet worden ontdekt. Een bureau dat in de verkoopfase alles belooft en pas tijdens de bouw beperkingen meldt, hoort niet op de shortlist.

Een sterke scope begint met het probleem, niet met een lijst knoppen. “Een dashboard bouwen” is geen bruikbare opdracht. “De operationsmanager moet dagelijks zien welke orders vastlopen en zelfstandig de oorzaak kunnen terugvinden” geeft richting aan gegevens, rollen, meldingen en acceptatie.

Daarna volgt een harde prioritering. Een eerste release moet niet alle wensen bevatten. De indeling must-have, should-have en nice-to-have voorkomt dat een project onnodig zwaar start.

Een must-have is nodig om de kernwaarde te leveren. Een should-have verbetert de werking, maar kan tijdelijk handmatig worden opgevangen. Een nice-to-have hoort pas op de planning wanneer de eerste gebruikers aantonen dat de functie waarde toevoegt.

Voor een klantportaal kan de eerste release bijvoorbeeld bestaan uit inloggen, orderstatus bekijken en een bericht ontvangen bij een wijziging. Een uitgebreide rapportage, mobiele notificaties en een slimme aanbevelingsfunctie kunnen wachten. Dat is geen karigheid, maar risicobeheersing.

Een offerte moet minstens deze onderdelen bevatten:

• Acceptatiecriteria per onderdeel: beschrijf wat de gebruiker moet kunnen doen en wanneer een functie als geslaagd geldt.
• Mijlpalen en datums: koppel werkende resultaten aan controlepunten, niet alleen aan een einddatum.
• Doorlooptijd en afhankelijkheden: benoem wat de leverancier nodig heeft van de opdrachtgever, zoals testdata, API-documentatie en beslissingen.
• Technische uitgangspunten: leg hosting, licenties, testomgevingen, externe diensten en beheer vast.
• Opleverdefinitie: bepaal of oplevering betekent dat code is gebouwd, dat acceptatie is afgerond of dat de productieomgeving stabiel draait.

Nederlandse ICT-projecten laten zien waarom deze discipline nodig is. Bij overheidsprojecten is slechts 30% succesvol. Bij projecten vanaf €7,5 miljoen daalt dat naar 7%, terwijl 36% van de grote projecten nooit in gebruik wordt genomen en 57% niet volgens plan verloopt, volgens de analyse over mislukte ICT-projecten bij de overheid. De geschatte maatschappelijke schade bedraagt €4 tot €5 miljard per jaar.

Voor een mkb'er is de les eenvoudig. Begin met een compacte fixed-price fase 0, gericht op een afgebakende MVP. Plan die fase op zes tot tien weken wanneer de scope dat toelaat, neem een kill-criterium op bij budgetoverschrijding en laat beide partijen een scopebevestiging ondertekenen voordat de eerste sprint start.

Leg ook vast wie eigenaar is van de broncode, cloudaccounts, domeinen, databases en API-sleutels. Zonder die afspraken kan een bedrijf na oplevering afhankelijk blijven van een individuele ontwikkelaar. Meer aandacht voor de financiële kant staat in de uitleg over maatwerksoftwarekosten, maar geen enkele prijsinschatting vervangt een concrete scope.

Een contract moet het project niet vertragen, maar onduidelijkheid wegnemen. De drie belangrijkste blokken zijn intellectueel eigendom, onderhoud en doorontwikkeling. Als die onderwerpen pas na de eerste storing worden besproken, staat de opdrachtgever zwak.

Bij intellectueel eigendom hoort een expliciete overdracht van broncode, ontwerpen, documentatie en gemaakte configuraties. Leg vast vanaf welk moment de opdrachtgever rechten verkrijgt en welke open-sourcecomponenten of bestaande libraries buiten de overdracht vallen. Accounts bij GitHub, hosting en externe diensten horen bij voorkeur op naam van de opdrachtgever te staan.

Onderhoud vraagt om concrete afspraken. Beschrijf responstijden, oplostijden, prioriteiten, escalatie en rapportage. Een service level agreement moet niet alleen beschikbaarheid benoemen, maar ook aangeven wat een storing is en welke uitzonderingen gelden. Voor een heldere uitleg van wat is een service level agreement kan een opdrachtgever vooraf de begrippen en verantwoordelijkheden nalopen.

API-koppelingen verdienen een apart onderdeel. Neem daarin op:

• Sleutelbeheer: wie maakt, bewaart, roteert en intrekt API-sleutels?
• Datagebruik: welke gegevens worden uitgewisseld en voor welk doel?
• Rate limits: wat gebeurt er wanneer een externe dienst verzoeken beperkt?
• Storingen bij derden: wie detecteert de fout, wie communiceert en wie bouwt een tijdelijke oplossing?
• Wijzigingen: hoeveel aanpassing valt onder onderhoud en wanneer wordt het doorontwikkeling?

Een goede exit-clausule beschrijft hoe de samenwerking eindigt. De opdrachtgever moet toegang krijgen tot code, documentatie, data, deploymentinformatie en accounts. Bij bedrijfskritische software kan een escrow-regeling voor de broncode extra zekerheid bieden wanneer de leverancier wegvalt.

Een vaste contractchecklist bevat dus eigendom, licenties, privacy, beveiliging, acceptatie, garantie, SLA, tarieven, wijzigingsprocedure, exit, escrow en geschillenbeslechting. Vooral vage oplevercriteria veroorzaken later discussie. “De applicatie is klaar” zegt niets zolang niet is vastgelegd welke scenario's getest en goedgekeurd moeten zijn.

Een sprintproces maakt ontwikkeling zichtbaar voor een opdrachtgever die niet programmeert. De leverancier plant het werk in korte cycli, toont werkende functionaliteit en verwerkt feedback op basis van prioriteit. Daardoor ontstaat controle voordat een groot budget al is besteed.

Een praktische sprintindeling duurt twee weken. Aan het begin bepalen opdrachtgever en team het sprintdoel. Tijdens korte dagelijkse stand-ups melden teamleden voortgang en blokkades. Halverwege kan een informele controle plaatsvinden, aan het einde volgt een demo met echte functionaliteit. De retrospective gebruikt het team om afspraken en werkwijze aan te scherpen.

Een Product Owner hoeft geen code te beoordelen. Die persoon moet wel prioriteiten stellen, acceptatiecriteria controleren en snel beslissen wanneer een requirement niet duidelijk is. De backlog beschrijft het werk in user stories, bijvoorbeeld: “Als planner wil ik een foutieve order kunnen markeren, zodat de administratie weet welke actie nodig is.”

Story points helpen het team om relatieve omvang te bespreken. Een burndown-chart laat zien hoeveel gepland werk nog openstaat. Geen van beide is een financiële garantie. De demo is belangrijker, omdat daar zichtbaar wordt of de software het bedrijfsproces werkelijk ondersteunt.

Feedback hoort via één aangewezen Product Owner te lopen. Wanneer drie managers rechtstreeks opdrachten aan developers geven, verandert de sprint voortdurend en verdwijnt de prioriteit. Een wijziging die niet noodzakelijk is voor het sprintdoel gaat naar de backlog voor een volgende sprint.

Een verzamelde set Nederlandse softwareprojecten rapporteerde bij Agile een stijging van het aandeel succesvol afgeronde projecten van 26% naar 43%. Tegelijk belandde 45% in de problemenzone en mislukte 12% volledig, volgens het rapport over grip op de voortgang van softwareprojecten. Agile werkt dus niet als ritueel. Het vraagt duidelijke requirements, realistische planning en communicatie.

Een bruikbaar sprintplanningssjabloon helpt om doel, backlog, afhankelijkheden en acceptatie vooraf vast te leggen.

Voor een praktische uitleg van het sprintproces kan deze video dienen als aanvullend vertrekpunt:

De livegang is geen eindstreep. Een professionele oplevering bevat een acceptatietest in de productieomgeving, overdracht van broncode en accounts, actuele documentatie en een kennissessie voor het interne team. Zonder die overdracht bezit een organisatie misschien software, maar niet de kennis om haar te beheren.

De eerste 12 tot 36 maanden vragen structurele aandacht. Hosting en monitoring houden beschikbaarheid en foutmeldingen zichtbaar. Securitypatches beperken kwetsbaarheden. Dependency-updates voorkomen dat de applicatie vastloopt op verouderde frameworks. API's van Exact, AFAS, SAP of andere leveranciers kunnen veranderen, waardoor koppelingen opnieuw getest en aangepast moeten worden.

AI voegt een extra beheervraag toe. Organisaties moeten bepalen welke gegevens naar een model mogen, hoe uitkomsten worden gecontroleerd en wat er gebeurt wanneer een model een verkeerde classificatie maakt. In Nederland ontwikkelt 58% van de organisaties software met ondersteuning van genAI, terwijl 56% nog traditioneel codeert en 94% zorgen heeft over gebrek aan regie, volgens het onderzoek naar agentic AI en regie. De bron noemt daarmee vooral een governanceprobleem, niet alleen een technische kans.

Een onderhoudscontract werkt het best met een vast basisblok en een flexibel blok. Het basisblok dekt monitoring, incidenten, patches en technisch beheer. Het flexibele deel betaalt voor verbeteringen op basis van gebruikersfeedback, nieuwe integraties of proceswijzigingen.

Een opdrachtgever die direct na oplevering afscheid neemt van de leverancier, bespaart meestal op de verkeerde plek. Binnen korte tijd gaat kennis verloren, worden kleine problemen groter en moet opnieuw worden ingewerkt. Nazorg hoort daarom al in de offerte en het contract te staan, niet in een paniekgesprek na de eerste storing.

De juiste partner hangt af van de mate waarin het probleem is afgebakend, de benodigde continuïteit en de AI-ambitie. Een freelancer past bij een overzichtelijke opdracht met één duidelijke eigenaar. Een gespecialiseerd bureau is logischer wanneer integraties, beveiliging, UX en beheer samenkomen. Een eigen team past wanneer software een kernonderdeel van de organisatie wordt en structurele productontwikkeling nodig is.

Hoe lang duurt een eerste MVP? Een eerste MVP kan binnen zes tot tien weken worden gepland wanneer de scope compact is, volgens de aanbevolen fixed-price fase. De werkelijke doorlooptijd hangt af van besluitvorming, testdata, koppelingen en beschikbaarheid van de opdrachtgever. Een leverancier die zonder deze vragen een harde datum belooft, verkoopt vooral zekerheid.

Wie bezit de broncode en AI-modellen? De opdrachtgever moet contractueel laten vastleggen wie eigenaar is van broncode, ontwerpen, data, prompts, configuraties en eventuele modelaanpassingen. Bij externe AI-diensten ligt het model zelf doorgaans niet bij de opdrachtgever. Wel moeten gebruiksrechten, dataverwerking, opslag en overdraagbaarheid van de ontwikkelde applicatielogica duidelijk zijn.

Wat zijn de risico's van AI-integraties met bestaande API's? AI kan ongestructureerde informatie verwerken, maar levert niet automatisch correcte beslissingen. De integratie moet toegangsrechten, logging, foutafhandeling, menselijke controle en een veilige fallback bevatten. Bij wijzigingen in een bestaande API moet duidelijk zijn wie de koppeling monitort en wie de aanpassing uitvoert.

Voor organisaties die maatwerk webapplicaties, klantportalen, API-koppelingen, legacy-modernisering en AI-workflows willen combineren, biedt MG Software ontwikkeling, iteratieve sprints, hosting, monitoring en onderhoud vanuit Haarlem voor opdrachtgevers in heel Nederland. Laat een eerste gesprek niet beginnen met een losse featurelijst, maar met het bedrijfsproces, de gewenste MVP, de integraties en het beheer over de eerste jaren.

MG Software helpt mkb-bedrijven en startups met maatwerksoftware, webapplicaties, API-koppelingen en AI-integraties die aansluiten op bestaande processen. Bezoek MG Software en bespreek welke compacte eerste release, technische aanpak en onderhoudsstructuur bij de organisatie passen.