Wat kost maatwerk software laten maken?

Wat is maatwerk software precies?

Maatwerk software is software die specifiek voor uw organisatie wordt gebouwd, op basis van uw processen, data en gebruikers. Dat staat tegenover een standaardpakket (SaaS, off-the-shelf) waarin u zich aanpast aan de manier waarop de leverancier denkt dat het werk gedaan moet worden.

Het verschil zit niet alleen in het product, maar vooral in de denkrichting. Bij een SaaS-pakket vraagt u zich af welke functionaliteit u nodig heeft van een vast menu. Bij maatwerk software vraagt u zich af hoe uw proces er idealiter uitziet en bouwt u software die dat proces ondersteunt. De vraag "wat kost maatwerk software?" is daarom moeilijker te beantwoorden dan "wat kost dit SaaS-abonnement?" — bij maatwerk hangt het antwoord af van wat u precies wil bouwen.

In de praktijk zien we drie smaken: volledig maatwerk vanaf scratch, maatwerk bovenop een platform (bijvoorbeeld een eigen applicatie die hergebruik maakt van Salesforce, SAP of een low-code-fundament), en maatwerk-koppelingen die bestaande pakketten aan elkaar lijmen tot iets dat voor uw situatie werkt. De kosten verschillen per smaak — meer hierover in de sectie over kostendrivers.

Wanneer is maatwerk de juiste keuze?

Maatwerk is niet altijd de slimste keuze. Een goed bureau adviseert net zo vaak om niet te bouwen als om wel te bouwen. We zien in praktijk vijf situaties waarin maatwerk meerwaarde oplevert ten opzichte van een standaardpakket:

• Uw proces is uw concurrentievoordeel. Als u sneller, slimmer of nauwkeuriger werkt dan de markt, wil u dat proces niet platdrukken in een SaaS-template. Dan past maatwerk.
• Geen enkel pakket dekt uw werkelijkheid. U heeft SaaS A geprobeerd, SaaS B vergeleken, en in beide gevallen blijft 30 tot 50 procent van uw werk in Excel of in iemands hoofd hangen.
• Licentiekosten lopen uit de hand. Bij voldoende gebruikers tikt een per-seat-licentie hard aan. Op een bepaald moment is een eenmalige bouwinvestering — plus beheer — voordeliger dan de licentie blijven betalen.
• U bent afhankelijk van koppelingen met systemen die uw SaaS niet officieel ondersteunt. Maatwerk is dan vaak goedkoper dan het lapwerk om de standaardoplossing draaiend te houden.
• U wil eigenaarschap van de software en de data. Bij SaaS huurt u functionaliteit. Bij maatwerk bezit u het. Dat heeft strategische en financiele gevolgen.

Komt geen van deze situaties bij u voor? Dan is een goed gekozen SaaS-pakket waarschijnlijk de betere optie. Een dieper beslismodel hierover beschrijven we in ons artikel build vs buy software — verplichte kost voordat u een offertetraject ingaat.

Wat drijft de kosten van maatwerk software?

Wie het antwoord "dat hangt ervan af" frustrerend vindt, krijgt hier een eerlijker antwoord: het hangt af van een paar concrete factoren die we hieronder uitleggen. Twee bedrijven die allebei "een planningssysteem" willen, kunnen totaal verschillende projectkosten hebben — soms ordes van grootte uit elkaar.

1. Scope en complexiteit van de business-logica

Een formulier dat een database vult is goedkoop. Een planningsmodule die 30 monteurs, 200 klanten, materiaalvoorraad, reistijden, skills en SLA's tegen elkaar afweegt om de beste planning te vinden is dat niet. De complexiteit van de logica — niet het aantal schermen — bepaalt het grootste deel van de bouwtijd.

2. Aantal en aard van integraties

Elke koppeling met een ander systeem brengt eigen werk mee: authenticatie, datamapping, foutafhandeling, monitoring en versie-onderhoud. Een koppeling met een modern systeem met goede API's en documentatie is sneller te bouwen dan een koppeling met een legacy-systeem of een SaaS-pakket dat alleen CSV-exports kent.

3. Technische niet-functionele eisen

Eisen die nooit op een functioneel ontwerp staan maar wel grote impact hebben: schaalbaarheid (kan het systeem met tien keer zoveel gebruikers om?), beschikbaarheid (mag het 's nachts 30 minuten plat?), security (welke standaarden, audit-trail, MFA, encryptie-at-rest?), privacy en compliance (AVG, NEN 7510, ISO 27001, DORA), en performance-eisen voor bepaalde flows.

4. Team-grootte aan onze kant

Meer mensen op een project leidt niet lineair tot meer snelheid. Een team van twee senior developers en een ontwerper kan vaak meer waarde leveren dan een team van zes junioren, omdat de coordinatielast bij grote teams stevig oploopt. We werken bij voorkeur met kleine, multidisciplinaire teams — dat houdt de overhead beperkt en de inhoudelijke kwaliteit hoog.

5. Eisen aan ontwerp en user experience

Een interne tool voor vijf medewerkers heeft een ander kwaliteitsniveau nodig dan een klantportaal dat het visitekaartje van uw organisatie is. Investeringen in user research, prototyping, design-iteraties en gebruiks­testen zijn keuzes die u maakt; ze leveren bewezen waarde bij klantgerichte applicaties en zijn vaak overkill bij smalle interne tools.

6. Doorlooptijd en startmoment

Een traject dat u in een paar sprints wil hebben is duurder per opgeleverde feature dan een traject dat over een rustiger ritme verspreid mag worden. Hetzelfde geldt voor projecten met harde deadlines — buffers in de planning kosten geld.

Wat zit er allemaal in een maatwerk-traject?

Veel kosten-misverstanden ontstaan omdat klanten bij "software bouwen" alleen aan programmeren denken. In werkelijkheid is programmeren ongeveer de helft van de tijd in een gezond traject. De rest gaat naar werk dat net zo belangrijk is voor het eindresultaat:

• Onderzoek en discovery — proces in kaart brengen, betrokkenen spreken, bestaande systemen inventariseren, risico's identificeren.
• UX-ontwerp en prototyping — schermflows, prototypes, gebruikerstests, design-systeem opzetten zodat schermen consistent blijven.
• Technische architectuur — keuzes over technologie, datamodel, deploymentstrategie en integratiepatronen.
• Bouw — het daadwerkelijke programmeren in sprints.
• Testing — geautomatiseerde tests, handmatige test-rondes, gebruiker-acceptatie-tests.
• Security en privacy — bedreigingsmodellen, code-review, soms een externe pentest, AVG-aanpak.
• Deployment en infrastructuur — hostingomgeving inrichten, CI/CD-pipeline, monitoring, back-ups, alerting.
• Documentatie — technische documentatie voor toekomstig beheer en gebruikersdocumentatie voor uw team.
• Training en in-gebruikname — uw team meenemen in het nieuwe systeem, change-management.
• Beheer en doorontwikkeling — na livegang gaat het werk door; er komen vragen, kleine wijzigingen, security-updates en nieuwe wensen.

Een offerte die alleen de bouw-uren noemt is geen complete offerte. Vraag expliciet hoe de andere posten zijn ingeschat — staan ze niet in de offerte, dan vallen ze later vermoedelijk als meerwerk uw kant op.

Verschil tussen projectbudget en sprintbudget

Er bestaan twee fundamenteel verschillende manieren om met een budget om te gaan in een softwareproject — en het verschil bepaalt zowel uw risico als uw flexibiliteit.

Projectbudget (fixed price)

De leverancier zet een vaste prijs op een vooraf uitgewerkte scope. Lijkt veilig: u weet wat u betaalt. In praktijk leidt het vaak tot een van twee uitkomsten. Of de scope verandert tijdens het traject (en dan komt er meerwerk-discussie), of de leverancier moet aan de scope vasthouden (en dan krijgt u letterlijk wat in het document stond, ook als u tijdens de bouw doorhad dat het anders moet).

Sprintbudget

U koopt een team voor een afgesproken aantal sprints. Aan het begin van elke sprint kiest u — samen met het team — wat de prioriteit is. U mag bijsturen op basis van wat u in de vorige sprint heeft gezien. Het budget blijft voorspelbaar (u weet wat een sprint kost), maar de inhoud kan groeien met uw inzicht.

Wij werken bij voorkeur met sprintbudget. Waarom? Omdat we in alle eerlijkheid bij de start van een traject niet álles weten wat we onderweg gaan ontdekken. Een fixed-price scope dwingt iedereen om in maand één te beslissen wat de software in maand zes moet kunnen — dat klopt zelden. Sprintbudget houdt de regie bij u, sprint voor sprint, met volledig zicht op wat er opgeleverd is en wat de volgende stap waard is.

Verborgen en lopende kosten

De bouw is een eenmalige investering, maar maatwerk software heeft ook structurele kosten. Wie alleen op de bouw-offerte rekent, komt later voor verrassingen te staan. Reken in elk geval met de volgende posten:

• Hosting en infrastructuur — servers, database, opslag, CDN, eventueel multi-region. Schaal-afhankelijk.
• Monitoring en observability — error-tracking, performance-monitoring, log-aggregatie. Tools als Sentry of Datadog hebben een licentie.
• Third-party SaaS-licenties — alle tools die uw software gebruikt onder water (mailservice, betaalprovider, identity-provider, kaart-API, AI-API's).
• Security-onderhoud — kwetsbaarheden in dependencies worden bijna dagelijks ontdekt. Wie ze niet bijwerkt, loopt risico.
• Koppelings-onderhoud — als een ander systeem zijn API verandert (en dat gebeurt), moet uw koppeling mee.
• Doorontwikkeling — geen enkele applicatie blijft drie jaar staan zoals hij opgeleverd is. Uw business verandert; de software moet mee.
• Beheercontract — een leverancier die bereikbaar is voor vragen, storingen en kleine wijzigingen kost geld, maar bespaart het meervoud aan paniekuren in eigen huis.

Een vuistregel die in onze sector vaak rondzingt: reken jaarlijks met een aanzienlijk percentage van het bouwbudget aan beheer en doorontwikkeling. Het exacte percentage hangt af van hoe groot, kritisch en koppelings-rijk uw applicatie is. Wij rekenen dit bij elke offerte transparant uit — niet als verrassing, maar als onderdeel van de business case.

Hoe maakt u offertes apples-to-apples vergelijkbaar?

Drie offertes voor "hetzelfde" project kunnen ver uiteen lopen in totaalbedrag — niet omdat een leverancier duur is, maar omdat er fundamenteel andere dingen in de offertes staan. Om eerlijk te kunnen vergelijken, normaliseer in elk geval op deze punten:

1. Welke discovery- en ontwerpfase zit erin? Sommige leveranciers starten direct met bouwen. Anderen besteden eerst tijd aan onderzoek. Beide kan, maar het beïnvloedt de prijs en het risico.
2. Welke kwaliteit van testing? Wordt er geautomatiseerd getest of alleen handmatig? Is een externe test-ronde meegenomen?
3. Security en privacy — zit er een dreigingsanalyse in? Een pentest? Een AVG-uitwerking?
4. Beheer en doorontwikkeling — wordt deze post genoemd, of valt 'ie buiten scope? Vraag een indicatie voor het eerste jaar na livegang.
5. Hosting en licenties — wordt dit door de leverancier afgenomen of bouwt u dat zelf?
6. Eigendomsrechten — wie is eigenaar van de code, het ontwerp en de data? Krijgt u toegang tot een eigen Git-repository?
7. Team-samenstelling — wie zit er op uw project, hoe ervaren, met welke rollen? Een offerte met "5 FTE" zonder rolverdeling zegt weinig.
8. Pricing-model — fixed-price, sprintbudget, T&M, dedicated team? Niet vergelijkbaar als de modellen verschillen.

Vraag elke leverancier dezelfde aanvullende informatie en leg de antwoorden naast elkaar. U zult zien dat het verhaal achter de prijs veel meer inzicht geeft dan het bedrag onderaan de pagina.

De vier gangbare pricing-modellen

Op de Nederlandse markt komt u in praktijk vier varianten tegen. Geen ervan is goed of fout — ze passen bij verschillende situaties.

Voor de meeste maatwerk-projecten adviseren wij sprintbudget. Het verenigt voorspelbaarheid (u weet wat een sprint kost) met flexibiliteit (u stuurt op inhoud sprint-voor-sprint). Voor het bredere plaatje van wat maatwerk software bouwen aan onze kant inhoudt, en hoe wij sprintbudget in praktijk vormgeven, zie onze dienstpagina.

Voor verwante kostenvragen rond andere soorten projecten zijn ook onze artikelen over wat een app laten maken kost en wat een website laten maken kost nuttige leesstof. Voor grotere organisaties die nadenken over modernisering of vervanging van interne systemen verwijzen we naar enterprise software laten ontwikkelen, waar we ingaan op trajecten met meer betrokkenen, compliance-eisen en koppelings-complexiteit.

Veelgestelde vragen

Wanneer is maatwerk goedkoper dan een SaaS-licentie?

Doorgaans op het moment dat licentiekosten over een aantal jaar opgeteld de bouw plus beheer overstijgen, of wanneer een SaaS-pakket dwingt tot lapwerk dat uw team meer tijd kost dan het bespaart. De omslag ligt verschillend per organisatie; ruwweg geldt: hoe specifieker uw proces en hoe meer gebruikers, hoe eerder maatwerk de business case wint.

Kunnen we klein beginnen?

Ja, en dat raden we ook aan. We starten meestal met een afgebakende eerste versie die snel waarde levert — vaak één kritisch deelproces — en breiden uit op basis van wat het oplevert. Zo voorkomt u dat u eerst maanden bouwt voordat de eerste eindgebruiker iets ziet.

Wat is sprintbudget precies?

U koopt een team voor een afgesproken ritme — meestal twee weken per sprint. Aan het begin van elke sprint plant u samen met het team wat er opgepakt wordt; aan het eind van elke sprint demonstreren we het resultaat en plant u de volgende. De kosten per sprint zijn vast; de inhoud is flexibel.

Kunnen we tussentijds bijsturen?

Bij sprintbudget en dedicated-team-modellen is bijsturen ingebouwd in de werkwijze. Bij fixed-price-trajecten is bijsturen mogelijk, maar gaat het via een formele meerwerk-route — daarom is fixed-price minder geschikt voor projecten waarin u onderweg leert wat u eigenlijk wil.

Wie is eigenaar van de code?

U bent eigenaar van de code, het ontwerp en de documentatie die we voor u maken. We leveren toegang tot een eigen Git-repository en alle bijbehorende infrastructuur. Bij eventuele beëindiging van de samenwerking houdt u alles wat u betaald heeft — geen lock-in op onze tooling.

Wat gebeurt er na livegang?

Een applicatie is na livegang niet "klaar"; er komen vragen van gebruikers, kleine wijzigingen, security-updates en wensen voor nieuwe functionaliteit. We bieden hiervoor beheer-afspraken in verschillende intensiteiten — van een minimaal pakket voor security en bereikbaarheid tot doorlopende doorontwikkeling met een vast sprintteam.