De belangrijkste punten

  • Vraag wie eigenaar is van code en data en op wiens naam de hosting staat; een vaag antwoord is een rode vlag.
  • Laat zien wie er echt gaat bouwen en hoe je elke twee weken iets werkends te zien krijgt.
  • Vraag naar het prijsmodel én naar onderhoud, want de kosten na oplevering bepalen de rekening op lange termijn.
  • Bel referenties zelf en vraag wat er misging; elk project heeft een tegenvaller.

In het kort

Een softwarebureau kies je niet op de mooiste presentatie, maar op de antwoorden op tien concrete vragen: wie eigenaar wordt van de code, waar de software draait, hoe je er weer vanaf kunt, wie er echt bouwt, hoe je voortgang ziet, hoe de communicatie loopt, wat het prijsmodel is, wat onderhoud inhoudt, hoe beveiliging geregeld is en wat eerdere klanten zeggen. Stel ze in het eerste gesprek en let minstens zo goed op hoe er geantwoord wordt als op wat er gezegd wordt. Een bureau dat deze vragen prettig vindt, is meestal het bureau dat je zoekt.

Vraag 1 tot en met 3: eigenaarschap, hosting en exit

1. Wie is eigenaar van de code en de data?

Dit is de belangrijkste vraag, en verrassend vaak staat het antwoord nergens op papier. Het goede antwoord: jij. De broncode staat in een repository op jouw naam of wordt bij elke oplevering aan je overgedragen, en de overeenkomst legt vast dat het intellectueel eigendom bij jou ligt.

De data staat in een database waar jij bij kunt en die je in een gangbaar formaat kunt exporteren. Vraag door als het antwoord is dat je een licentie krijgt: dan ben je huurder, geen eigenaar. Waarom dit zo zwaar weegt, lees je in vendor lock-in vermijden.

2. Waar draait de software en op wiens account?

Software moet ergens draaien. Vraag welke hostingpartij dat is, in welk land de servers staan en of het hostingaccount op jouw naam staat of op die van het bureau. Voor persoonsgegevens wil je hosting binnen de EU en een verwerkersovereenkomst. Een account op jouw naam waarbij het bureau beheerder is, geeft je de vrijheid om de toegang van het bureau in te trekken zonder dat de software stopt.

3. Wat gebeurt er als we uit elkaar gaan?

Elke samenwerking eindigt ooit. Vraag concreet: hoe ziet een overdracht eruit, wat krijg ik mee, is er documentatie, hoeveel tijd kost het en wat betaal ik ervoor. Een goed bureau heeft dit eerder gedaan en kan het in vijf zinnen uitleggen. Een bureau dat zegt dat het nog nooit is voorgekomen, heeft er niet over nagedacht.

Vraag 4 tot en met 6: wie bouwt, hoe je voortgang ziet en hoe je contact houdt

4. Wie gaat er daadwerkelijk bouwen?

Het gesprek voer je vaak met een accountmanager of oprichter; de code schrijft iemand anders. Vraag wie dat is, hoeveel ervaring die persoon heeft met vergelijkbare projecten, of het werk wordt uitbesteed en of je die bouwer spreekt tijdens het project. Uitbesteden is niet per definitie slecht, maar je wilt het weten, en je wilt weten wie verantwoordelijk is voor de kwaliteit.

5. Hoe en wanneer zie ik iets werken?

Het antwoord dat je wilt horen: in korte sprints, met aan het eind van elke sprint een demo van werkende software, en een eerste versie die je zelf kunt gebruiken binnen weken in plaats van maanden. Vraag ook waar je de voortgang tussentijds kunt volgen. Een bureau dat pas na maanden iets laat zien, legt het risico van verkeerde aannames volledig bij jou. Hoe wij dat ritme aanhouden, staat beschreven in onze werkwijze.

6. Wie is mijn aanspreekpunt en hoe snel krijg ik antwoord?

Vraag naar één vast aanspreekpunt, naar de manier van communiceren tijdens het project (een gedeeld kanaal, een wekelijks overleg, een ticketsysteem) en naar de reactietijd bij een storing na oplevering. Let in het voortraject al op hoe snel en hoe helder het bureau reageert; dat verandert na de handtekening zelden ten goede.

Vraag 7 en 8: prijsmodel en onderhoud

7. Hoe zit het prijsmodel in elkaar?

Er zijn grofweg drie modellen: een vaste prijs voor een vaste scope, een prijs per sprint of per periode, en nacalculatie op basis van uren. Geen van de drie is per definitie beter. Belangrijker is dat je begrijpt wat er gebeurt als de scope verandert, wat er wel en niet in de prijs zit (ontwerp, tests, hosting, licenties, projectbegeleiding) en wanneer je betaalt.

Vraag om een voorbeeld van een eerdere offerte, inclusief hoe het project uiteindelijk verliep. Meer over de factoren die de prijs bepalen lees je in wat kost maatwerksoftware.

8. Wat houdt onderhoud in en wat kost het na oplevering?

Software is nooit af. Bibliotheken krijgen beveiligingsupdates, koppelingen veranderen, browsers veranderen.

Vraag wat er in een onderhoudsafspraak zit: monitoring, updates, back-ups, kleine aanpassingen, reactietijd bij storingen. En vraag wat er gebeurt als je geen onderhoud afneemt. Een bureau dat onderhoud verplicht stelt om de code te mogen blijven gebruiken, verkoopt je geen software maar een abonnement.

Tip. Vraag naar de verhouding tussen onderhoudskosten en bouwkosten, en naar wat er het afgelopen jaar aan onderhoud is gedaan bij een vergelijkbaar project. Zo krijg je een beeld van de werkelijke kosten over meerdere jaren, in plaats van alleen de bouwprijs.

Vraag 9 en 10: beveiliging en referenties

9. Hoe is beveiliging geregeld?

Je hoeft geen techniek te kennen om dit te toetsen. Vraag: hoe worden wachtwoorden en sleutels opgeslagen, is er tweestapsverificatie, wie heeft toegang tot de productieomgeving, hoe worden back-ups gemaakt en getest, en hoe worden beveiligingsupdates bijgehouden. Vraag ook wat het bureau doet bij een datalek en of dat is vastgelegd. Een goed antwoord is concreet en rustig; een slecht antwoord is dat je je daar geen zorgen over hoeft te maken.

10. Mag ik met eerdere klanten praten?

Vraag om twee of drie referenties van projecten die lijken op het jouwe, en bel ze zelf. Vraag niet alleen of ze tevreden zijn, maar wat er tegenzat, hoe het bureau daarmee omging en hoe het na de oplevering ging. Elk project heeft een tegenvaller; het verschil zit in de reactie. Bekijk daarnaast de gepubliceerde cases van het bureau en let op of ze de aanpak en het resultaat concreet beschrijven, of vooral bijvoeglijke naamwoorden gebruiken.

Rode vlaggen en goede tekenen

OnderwerpRode vlagGoed teken
EigenaarschapJe krijgt een licentie op hun platformCode in een repository op jouw naam, overdracht van het eigendom in het contract
VoortgangEerste oplevering na maandenElke twee weken een demo van werkende software
ScopeAlles wordt in één keer beloofdHet bureau stelt voor om kleiner te beginnen
PrijsOnduidelijk wat er bij een scopewijziging gebeurtHeldere afspraak per sprint of per wijziging
OnderhoudVerplicht abonnement om de software te mogen gebruikenOnderhoud als keuze, met duidelijke inhoud
TeamJe spreekt de bouwer nooitDe bouwer zit bij de demo
GesprekVooral praten over hun aanbodVooral vragen over jouw proces

Nog één teken dat niet in de tabel past: een bureau dat je ergens van afraadt. Wie zegt dat een standaardpakket met een koppeling in jouw geval slimmer is dan maatwerk, verdient het om teruggebeld te worden als je wél iets op maat nodig hebt. Hoe je die afweging zelf maakt, lees je in maatwerk of standaardpakket.

Zo gebruik je deze lijst

  1. Stuur de tien vragen vooraf naar de bureaus die je spreekt. Je krijgt betere antwoorden en je ziet wie de moeite neemt.
  2. Spreek met minstens twee bureaus en stel dezelfde vragen in dezelfde volgorde, zodat je kunt vergelijken.
  3. Vraag om de antwoorden op vraag 1, 2, 3 en 8 schriftelijk, en controleer of ze in de overeenkomst terugkomen.
  4. Bel de referenties voordat je tekent, niet erna.
  5. Begin klein: een eerste sprint of een eerste versie is de beste manier om te toetsen of de antwoorden kloppen.

Twijfel je tussen bureaus die allemaal goed antwoorden? Kies dan het bureau dat de meeste vragen over jouw proces stelde. Software op maat bouwen is vooral begrijpen wat er gebouwd moet worden, en dat begint bij luisteren.

Geschreven door het team van Dosya

Software- en automatiseringsstudio uit Rotterdam. We bouwen maatwerksoftware, automatiseren bedrijfsprocessen en koppelen systemen voor bedrijven in heel Nederland. Meer over ons