Software laten maken: wanneer maatwerk loont en hoe je begint.

Een proces loopt vast. Het team werkt in drie Excel-bestanden, gegevens worden twee keer ingevoerd en niemand weet welke versie klopt. Dan ligt de gedachte voor de hand: we laten gewoon software maken die precies doet wat wij willen. Soms is dat de juiste beslissing. Vaak is er een snellere en goedkopere route die eerst getest moet worden.

Deze gids helpt je die keuze goed te maken. Je leest wanneer maatwerk echt nodig is, hoe een softwaretraject verloopt, wat een MVP, een PRD en een BRD zijn, wat software laten maken kost en wat je contractueel in handen moet houden. Eén ding vooraf: Viralistic bouwt zelf geen maatwerksoftware. We werken aan strategie, design, websites en automatisering, en we helpen bedrijven de juiste vraag te stellen voordat ze ontwikkelaars inhuren. We hebben er dus geen belang bij om je een bouwproject te verkopen.

Heb je wel maatwerksoftware nodig?

Maatwerk is zelden de eerste stap, ook niet als je software voor je bedrijf wilt laten maken. Voordat je software op maat laat ontwikkelen, loont het om drie andere routes serieus te testen: standaardsoftware, no-code en het automatiseren van de tools die je al hebt. Pas als die alle drie tekortschieten, verdient maatwerk zijn prijs.

Neem twee zoekopdrachten die we vaak zien: een ledensysteem laten maken of groothandelssoftware laten maken. Voor allebei bestaan kant-en-klare pakketten die het grootste deel van het werk afdekken. De echte vraag is dan of het stuk dat ontbreekt een eigen systeem rechtvaardigt, of dat een koppeling tussen het pakket en je webshop, boekhouding of CRM volstaat.

Die laatste route wordt vaak onderschat. Met een workflowtool als n8n verbind je systemen die al goed werken, zodat gegevens zonder overtypen van de ene naar de andere plek gaan. Je kunt n8n in de cloud gebruiken of je eigen omgeving draaien, bijvoorbeeld via beheerde n8n-hosting in Europa. Hoe je zo’n traject aanpakt, lees je in onze gids over workflowautomatisering en op onze pagina over automatisering.

Vier vragen helpen je bepalen of maatwerk de juiste keuze is:

1. Is dit proces wat je onderscheidt van concurrenten, of is het administratie die elk bedrijf heeft?
2. Heb je minstens twee pakketten serieus getest, met een demo op je eigen gegevens?
3. Is er een vaste groep gebruikers die de software dagelijks gaat gebruiken?
4. Kun je naast de bouw ook het onderhoud de komende jaren betalen?

Beantwoord je drie of vier vragen met ja, dan is maatwerk het onderzoeken waard. Twijfel je bij de meeste, begin dan bij de routes hierboven, of zet eerst je digitale prioriteiten op een rij met een strategisch traject.

Zo verloopt software laten maken, stap voor stap

Een goed softwaretraject verloopt in acht stappen: discovery, requirements, ontwerp en prototype, MVP, bouw, testen, lancering en onderhoud. De eerste drie stappen kosten het minst en voorkomen de duurste fouten. Bureaus noemen ze anders, maar de volgorde is vrijwel altijd dezelfde.

1. Discovery: het probleem scherp krijgen

Je beschrijft het probleem, niet de oplossing. Wie heeft er last van, hoe vaak, en wat kost het nu aan tijd of fouten? Praat met de mensen die het werk doen, niet alleen met het management. Het resultaat is een korte probleemstelling met meetbare doelen.

2. Requirements vastleggen in een PRD

Je legt vast wat de software moet doen, voor wie en waarom. Dat document heet een PRD. Verderop lees je wat erin hoort.

3. UX/UI-ontwerp en een klikbaar prototype

Voordat er code wordt geschreven, ontwerp je de schermen. Eerst als wireframe, zonder kleur en typografie, zodat de route door de software centraal staat. Daarna als volledig ontwerp, bijvoorbeeld in Figma, waar je schermen met elkaar kunt verbinden tot een klikbaar prototype. Wie software wil laten ontwerpen of een software prototype wil laten maken, zit in deze fase. Een prototype laat gebruikers klikken en reageren voordat de bouw begint, en wijzigingen kosten hier nog uren in plaats van weken. Meer over deze stap lees je in onze gids over UX/UI-design.

4. MVP: de kleinste versie die iets bewijst

Je kiest de kleinste set functies waarmee echte gebruikers een echte taak kunnen uitvoeren. Al het andere komt later.

5. Bouwen in korte iteraties

Goede ontwikkelaars bouwen in korte rondes van één tot vier weken, met een demo aan het einde van elke ronde. Zo zie je steeds werkende software en kun je bijsturen voordat een verkeerde aanname duur wordt.

6. Testen met echte gebruikers en echte gegevens

Testen gaat verder dan klikken of een knop werkt. Denk aan functionele tests, beveiliging, snelheid onder belasting, en een acceptatietest waarin jouw team de software met echte gegevens gebruikt.

7. Lancering en overdracht

Bij de lancering hoort een plan voor de migratie van bestaande gegevens, training voor gebruikers en een overdracht met documentatie, toegang en broncode.

8. Onderhoud en doorontwikkeling

Software is na de lancering niet af. Afhankelijkheden krijgen beveiligingsupdates, besturingssystemen en browsers veranderen en gebruikers vragen om verbeteringen. Reken onderhoud dus mee in je budget vanaf de eerste offerte. Voor je website geldt hetzelfde, zoals je leest in onze gids over website onderhoud.

Wat is een MVP? De betekenis in gewone taal

MVP staat voor minimum viable product: de kleinste werkende versie van een product waarmee je leert of het probleem echt opgelost wordt. Eric Ries, die de term populair maakte met zijn boek The Lean Startup, omschreef het MVP in 2009 als de versie van een nieuw product waarmee een team met zo weinig mogelijk moeite zoveel mogelijk gevalideerde kennis over klanten verzamelt.

Het woord minimum zet mensen op het verkeerde been. Een goed MVP doet weinig, maar dat weinige doet het goed: één duidelijke taak voor één duidelijke groep gebruikers. Voor een groothandel kan dat een bestelportaal zijn waarin vaste klanten alleen nabestellingen plaatsen, zonder offertes, kortingsregels of retouren. Werkt dat, dan bouw je verder.

Een MVP wordt vaak verward met twee andere begrippen:

Wat is een PRD, en wat is een BRD?

Een PRD (product requirements document) beschrijft wat een product moet doen, voor wie en waarom. Een BRD (business requirements document) beschrijft wat de organisatie wil bereiken en waarom, nog voordat er een oplossing is gekozen. De BRD gaat dus over het waarom van het bedrijf, de PRD over het wat van het product. Hoe het technisch gebouwd wordt, werken de ontwikkelaars daarna uit in een technisch ontwerp.

Voor een kleiner bedrijf zijn BRD en PRD vaak één document. Dat is prima, zolang de bedrijfsdoelen er bovenaan in staan. Een goede PRD hoeft ook niet lang te zijn. Atlassian, de maker van Jira en Confluence, adviseert in zijn handleiding voor een PRD om net genoeg context te geven en details aan het ontwikkelteam over te laten. Een beknopte opzet:

1. Projectgegevens: wie er betrokken is, de status en de beoogde oplevering.
2. Doelen: de bedrijfsdoelen en hoe je succes meet.
3. Achtergrond: waarom dit nu nodig is en hoe het past in je strategie.
4. Aannames: wat je aanneemt over gebruikers, techniek en markt.
5. User stories: wat elke gebruiker moet kunnen, met succescriteria.
6. Interactie en ontwerp: links naar wireframes en het ontwerp in Figma.
7. Open vragen: wat nog besloten of uitgezocht moet worden.
8. Buiten scope: wat je bewust niet bouwt, nu of in de eerste versie.

Wij voegen daar zelf twee onderdelen aan toe, omdat ze in offertes het vaakst ontbreken: de koppelingen met bestaande systemen en de niet-functionele eisen, zoals beveiliging, snelheid, beschikbaarheid en de verwerking van persoonsgegevens onder de AVG.

Een PRD doet nog iets: het maakt offertes vergelijkbaar. Geef drie ontwikkelaars hetzelfde document en je vergelijkt prijzen voor hetzelfde werk, in plaats van drie verschillende interpretaties van een gesprek.

Wat kost software laten maken?

Software laten maken kost meestal tussen enkele duizenden en enkele honderdduizenden euro’s. Waar je uitkomt, hangt af van de omvang, het aantal koppelingen, gebruikersrollen, beveiligingseisen en wie het werk doet. Een vaste prijs per stuk bestaat niet, omdat elk project een andere vraag beantwoordt. Wie de kosten van software ontwikkelen wil inschatten, kijkt dus eerst naar de scope en pas daarna naar het uurtarief.

Nederlandse softwarebedrijven publiceren zelf indicaties. Die zijn nuttig als richting, maar het zijn geen onafhankelijke marktcijfers:

Deze factoren bepalen of je onder- of bovenin zo’n bandbreedte uitkomt:

• Omvang: het aantal schermen, stappen en uitzonderingen.
• Koppelingen: elke verbinding met boekhouding, webshop, CRM of ERP kost bouw- en testtijd.
• Gebruikers en rechten: één type gebruiker is eenvoudiger dan klanten, medewerkers en beheerders met elk eigen rechten.
• Gegevens en beveiliging: persoonsgegevens, betalingen of medische gegevens vragen om zwaardere eisen.
• Migratie: bestaande gegevens overzetten uit oude systemen of spreadsheets.
• Ontwerp: een sterk ontwerp kost vooraf tijd en bespaart later bouwuren.
• Doorlopende kosten: hosting, licenties, monitoring, beveiligingsupdates en doorontwikkeling.

Groot beginnen is het duurste risico. McKinsey en de Universiteit van Oxford onderzochten in 2012 meer dan 5.400 IT-projecten. Grote IT-projecten liepen gemiddeld 45 procent over budget en 7 procent uit in tijd, en leverden 56 procent minder waarde op dan voorspeld. Elk extra jaar looptijd verhoogde de budgetoverschrijding met 15 procent. Dat onderzoek ging over projecten van meer dan 15 miljoen dollar, maar de les geldt ook voor een mkb-project: hoe groter en langer de eerste versie, hoe groter de kans dat hij duurder uitvalt en minder oplevert. Klein beginnen met een MVP beperkt dat risico, en je leert eerder wat gebruikers echt nodig hebben.

Hoe kies je een partij om software te laten bouwen?

Kies een partner die eerst vragen stelt, werkende software laat zien voordat je de volledige bouw betaalt en heldere afspraken maakt over eigendom en onderhoud. Een lage uurprijs zegt weinig als het aantal uren onduidelijk is.

Stel deze vragen in het eerste gesprek:

• Hoe brengen jullie het probleem in kaart voordat je een prijs noemt?
• Kunnen we een betaalde discovery of een prototype doen, los van de bouw?
• Krijg ik een prijs per onderdeel, zodat ik kan kiezen wat in de eerste versie komt?
• Hoe vaak zie ik werkende software, en wie zit er in het team?
• Hoe testen jullie, en zit testen in de offerte?
• Wie is eigenaar van de broncode, en hoe verloopt de overdracht als we stoppen?
• Wat kost onderhoud per maand of per jaar, en wat valt eronder?
• Sluiten jullie een verwerkersovereenkomst als de software persoonsgegevens verwerkt?

Overweeg je software outsourcing buiten Nederland, let dan ook op tijdzone, voertaal, het toepasselijke recht in het contract en wie aanspreekbaar is als het misgaat. Een lager tarief weegt niet altijd op tegen extra afstemming.

Vraag bij twijfel om referenties van klanten met een vergelijkbaar project, en bel ze ook echt. Vraag hoe het project verliep, en vraag daarna wat er gebeurde toen iets misging. Dat tweede antwoord zegt meer.

Wat moet je zelf in handen houden?

Houd drie dingen altijd zelf in handen: de broncode en het intellectueel eigendom, alle accounts en toegang, en de documentatie. Zonder die drie ben je afhankelijk van één leverancier, ook als de samenwerking stopt.

Dat eigendom regel je niet vanzelf. In de Auteurswet zijn computerprogramma’s beschermde werken, en het auteursrecht ligt in beginsel bij de maker. Voor werknemers geldt een uitzondering, maar een extern bureau of een freelancer is geen werknemer. Volgens artikel 2 van de Auteurswet moet een overdracht van het auteursrecht schriftelijk worden overeengekomen en geleverd met een daartoe bestemde akte. Een zin in een offerte is daarvoor niet genoeg. Laat de overdracht of een passende licentie dus expliciet vastleggen, en laat het contract nalezen door een jurist.

Een praktische checklist:

• Repository: de broncode staat in een GitHub- of GitLab-omgeving op naam van jouw bedrijf. De ontwikkelaar krijgt toegang, niet andersom.
• Cloud en hosting: het account staat op jouw naam en jouw betaalgegevens, ook bij diensten als AWS of Firebase.
• Domein en e-mail: op naam van je bedrijf, met jou als beheerder.
• App stores en API-sleutels: ontwikkelaarsaccounts en sleutels van externe diensten horen bij jou.
• Documentatie: hoe de software is opgebouwd, hoe je hem installeert en hoe een nieuwe partij verder kan.
• Gegevens: je kunt je data op elk moment exporteren in een bruikbaar formaat.
• Escrow: houdt de leverancier toch de code, spreek dan een escrowregeling af, zodat je bij een faillissement bij de broncode kunt.

Dezelfde logica geldt voor je website. Ook daar wil je domein, hosting en ontwerpbestanden zelf bezitten, zoals we uitleggen in onze gids over een website laten maken.

Hoe wij helpen

Viralistic bouwt geen maatwerksoftware en doet zich ook niet zo voor. Wel helpen we je op de momenten waarop de duurste beslissingen vallen: vóór de bouw en ernaast.

Met onze strategie-aanpak kijken we naar je bedrijf als geheel. We beoordelen je tools en workflows en zetten initiatieven in de juiste volgorde. Soms is de uitkomst dat je helemaal geen maatwerk nodig hebt. Wat zo’n traject inhoudt, lees je in onze gids over digitale strategie.

Kies je wel voor maatwerk, dan helpen we je de vraag en de requirements scherp op papier te krijgen voordat je ontwikkelaars inhuurt. Zo vergelijk je offertes op hetzelfde werk. We vertalen je merk ook naar interfaces in Figma, van wireframe tot high-fidelity-ontwerp, zoals beschreven op onze pagina’s over design en webdesign.

Blijkt dat je bestaande tools volstaan, dan verbinden we ze met n8n en Claude. We spreken eerst de waarde af en bewijzen die met een paar workflows in productie, via onze automatiseringsaanpak.

Twijfel je of software laten maken de juiste stap is? Plan een strategisch gesprek. We vertellen je eerlijk welke route het meest oplevert, ook als dat een route is die wij niet uitvoeren.

Veelgestelde vragen

Wat kost het om software te laten maken?

Dat hangt af van omvang, koppelingen, gebruikersrollen en beveiligingseisen. Softwarebedrijf InnovaWare noemt €10.000 tot €25.000 voor een startup, €25.000 tot €100.000 voor een middelgroot bedrijf en €100.000 tot €500.000 voor een grote organisatie. Een ervaren ontwikkelaar rekent volgens Divtag €75 tot €150 per uur. Vraag altijd een prijs per onderdeel en reken onderhoud mee.

Wat is het verschil tussen maatwerksoftware en standaardsoftware?

Standaardsoftware is een kant-en-klaar pakket dat veel bedrijven gebruiken, meestal als abonnement. Je bent snel live, maar past je werkwijze deels aan het pakket aan. Maatwerksoftware wordt speciaal voor jouw proces gebouwd. Het past precies, maar kost meer, duurt langer en vraagt jarenlang onderhoud. Kies maatwerk alleen als je proces je onderscheidt of in geen enkel pakket past.

Kan AI of ChatGPT software voor je maken?

AI-assistenten zoals ChatGPT en Claude schrijven werkende code en maken snel een prototype. Ze nemen je de keuzes niet af: wat je bouwt, hoe je gegevens beveiligt, hoe het onderhouden wordt en wie verantwoordelijk is. Wil je AI-software laten maken die bijvoorbeeld e-mails verwerkt of documenten samenvat, dan volstaat vaak een workflow met n8n en Claude in plaats van een eigen applicatie. Wat zo’n workflow kan overnemen, lees je in onze gids over AI automatisering.

Hoe kan ik zelf software maken zonder te programmeren?

Met no-code-tools bouw je formulieren, databases en eenvoudige interne apps zonder code. Voor het verbinden van bestaande tools gebruik je een workflowtool zoals n8n. Begin met een klein, afgebakend proces en documenteer wat je bouwt. Groeit de tool uit tot iets waar je bedrijf op draait, dan is het tijd voor een PRD en een professionele partij.

Wat betekent SaaS?

SaaS staat voor software as a service: software die je via internet gebruikt tegen een abonnement, in plaats van die zelf te installeren of te laten bouwen. De leverancier host de software, houdt hem veilig en voert updates door. Denk aan een online boekhoudpakket of CRM. Voor veel bedrijfsprocessen is SaaS sneller en goedkoper dan maatwerk.

Van wie is de broncode als ik software laat maken?

Volgens de Auteurswet ligt het auteursrecht in beginsel bij de maker, en een extern bureau is geen werknemer. Wil je de broncode en het intellectueel eigendom zelf bezitten, leg de overdracht dan schriftelijk vast in een akte. Zorg daarnaast dat repository, cloudaccount en domein op naam van je bedrijf staan. Laat het contract nalezen door een jurist.