Je hebt een idee voor een digitale tool of intern systeem. Een standaardpakket past niet, dus je kijkt naar maatwerk. Maar hoe weet je of je een eerlijke offerte krijgt en of je aan het einde ook echt eigenaar bent van wat er gebouwd wordt? Dat zijn de vragen die je moet stellen voordat er ook maar één regel code wordt geschreven.
Wat maatwerk software precies inhoudt
Maatwerk software is een applicatie die speciaal voor jouw organisatie wordt ontwikkeld. Dat klinkt logisch, maar de praktijk is genuanceerder. Soms bouwt een bureau een bestaand intern framework om en noemt dat maatwerk. Soms krijg je een licentie op een white-label product met jouw logo erop. Dat zijn geen slechte oplossingen, maar je moet weten wat je koopt.
Vraag bij elke offerte expliciet: wordt dit volledig nieuw gebouwd, of wordt er een bestaande basis gebruikt? En als er een basis is, wie is dan eigenaar van die basis? Als het bureau de onderliggende code bezit, heb jij afhankelijkheid ingebouwd van dag één.
Broncode-eigendom is hier het sleutelwoord. Zorg dat in het contract staat dat jij na oplevering de volledige broncode bezit, inclusief alle libraries die specifiek voor jouw project zijn geschreven. Wat een bureau zelf heeft ontwikkeld vóór jouw project, hoeft het niet over te dragen. Maar wat ín jouw project is gebouwd, is van jou.
Hoe je offertes vergelijkt zonder appels en peren
Je vraagt drie offertes op. De een zegt 18.000 euro, de ander 42.000 euro, de derde 27.500 euro. Wat doe je daarmee? Zonder een gedetailleerde scope zijn deze bedragen betekenisloos. Een lage prijs kan betekenen dat er minder gebouwd wordt, dat er minder getest wordt, of dat onderhoud niet is meegenomen.
Vraag bij elke offerte een functionele specificatie mee. Dat is een document waarin staat wat de software precies moet doen, welke gebruikersrollen er zijn, welke integraties nodig zijn en wat er níet in zit. Bureaus die dit niet kunnen of willen leveren, zijn een risico. Je weet dan niet wat je koopt.
Let ook op wat er staat over testfases, acceptatieprocedures en oplevercriteria. Wanneer is de software “klaar”? Als dat nergens is vastgelegd, is het antwoord altijd: nooit helemaal. Of juist: wanneer het bureau zegt dat het klaar is. Geen van beide is een prettige positie.
Bureaus als Aspect werken doorgaans met vaste projectfases en tussentijdse acceptatiemomenten. Dat zie je ook terug in hoe zij offertes opbouwen: per fase, met duidelijke deliverables. Dat maakt vergelijken makkelijker, omdat je per fase kunt beoordelen wat je krijgt.
Onderhoudscontracten en wat daarin moet staan
Software is geen product dat je koopt en dan klaar is. Browsers worden bijgewerkt, servers krijgen nieuwe besturingssystemen, beveiligingslekken worden ontdekt. Als er niemand is die de software onderhoudt, veroudert die sneller dan je denkt.
Een onderhoudscontract is daarom geen luxe, maar een noodzaak. Maar let op wat erin staat. Er is een groot verschil tussen een contract dat alleen hosting en beschikbaarheid dekt, en een contract dat ook bugfixes, beveiligingsupdates en kleine aanpassingen omvat. Lees de kleine lettertjes.
Stel ook de vraag: wat gebeurt er als het bureau stopt? Heb jij toegang tot de serveromgeving? Staat de software op jouw hostingaccount of op dat van het bureau? Als het bureau failliet gaat of de samenwerking stopt, moet jij binnen een dag de software ergens anders kunnen draaien. Dat is alleen mogelijk als je de toegangsgegevens hebt en de broncode in bezit is.
Vraag altijd om escrow of directe toegang tot de repository. Een escrow-regeling betekent dat de broncode bij een derde partij wordt bewaard, zodat jij er altijd bij kunt als de relatie met het bureau eindigt. Niet elk bureau biedt dit standaard aan, maar het is een redelijk verzoek.
Waar je op let bij de oplevering
De oplevering is het moment waarop de meeste dingen misgaan. Niet omdat de software niet werkt, maar omdat verwachtingen niet zijn afgestemd. Wat jij als “klaar” ziet, is soms niet wat het bureau als “klaar” ziet.
Zorg voor een schriftelijke acceptatieprocedure vóór de bouw begint. Daarin staat hoe de oplevering wordt getest, wie dat doet, hoelang je de tijd hebt om fouten te melden en wat er daarna gebeurt. Zonder dit document ben je afhankelijk van goodwill.
Hieronder een korte checklist voor bij de oplevering:
- Heb je toegang tot alle omgevingen (productie, test, staging)?
- Zijn de inloggegevens van alle systemen aan jou overgedragen?
- Heb je de broncode ontvangen of toegang tot de repository?
- Is de documentatie aanwezig (technisch en functioneel)?
- Zijn er openstaande bugs geregistreerd en is er een planning voor herstel?
- Zijn de domeinnaam en SSL-certificaat op jouw naam geregistreerd?
- Is er een back-upstrategie en wie beheert die?
Loop deze lijst door vóór je de eindfactuur betaalt. Zodra die betaald is, verandert de dynamiek. Bureaus zijn minder snel geneigd om kleine punten op te lossen als de rekening al is voldaan.
Veelgestelde vragen over maatwerk software laten bouwen
Moet ik altijd kiezen voor maatwerk, of is een standaardpakket beter?
Dat hangt af van hoe specifiek jouw processen zijn. Als een standaardpakket 80 procent dekt en de rest aanpasbaar is, is dat vaak goedkoper en stabieler dan maatwerk. Maatwerk is zinvol als jouw werkwijze echt afwijkt van wat beschikbaar is, of als concurrentievoordeel afhankelijk is van die specifieke functionaliteit.
Wie is eigenaar van de software die een bureau voor mij bouwt?
Dat staat in het contract. Zonder expliciete afspraak geldt in Nederland dat de maker (het bureau) auteursrechthebbende is. Zorg dus altijd voor een schriftelijke overdracht van intellectueel eigendom bij oplevering.
Wat is een redelijke garantietermijn na oplevering?
Drie tot zes maanden is gebruikelijk voor het oplossen van bugs die voortvloeien uit fouten in de bouw. Nieuwe wensen of aanpassingen vallen daar niet onder. Leg dit vast in het contract, zodat er geen discussie ontstaat over wat een bug is en wat een feature request.
Leave a Reply