Drie offertes op tafel, drie totaal verschillende bedragen en drie bureaus die allemaal zeggen dat ze agile werken. Op dat moment merken de meeste organisaties dat een softwarebedrijf kiezen weinig met de laagste prijs te maken heeft en alles met vertrouwen, continuïteit en heldere afspraken.
Een softwarebedrijf ontwerpt, bouwt en onderhoudt software voor andere organisaties. Er zijn grofweg twee soorten: productbedrijven die één pakket ontwikkelen en aan veel klanten verkopen, en maatwerkbureaus die software bouwen rond de processen van één opdrachtgever. Wie software laat ontwikkelen, werkt vrijwel altijd met de tweede groep, en dan bepalen de mensen, de werkwijze en het contract het resultaat.
Hieronder staan negen vragen die het verschil blootleggen tussen een bureau dat goed presenteert en een partner die over vijf jaar nog naast je staat, gevolgd door de rode vlaggen, een invultabel en onze eigen antwoorden.
Wat een softwarebedrijf doet en waarom het type uitmaakt
De definitie van een softwarebedrijf op Wikipedia is breed: elk bedrijf dat software ontwikkelt of levert valt eronder. Voor jouw keuze is de tweedeling belangrijker. Een productbedrijf verkoopt licenties op een bestaand pakket; je start snel, betaalt per gebruiker en volgt de roadmap van de leverancier. Een maatwerkbureau bouwt software die van jou is en die aansluit op jouw processen, met een langer traject en meer eigen betrokkenheid.
Daartussen zit een derde vorm: een softwareontwikkelaar of een klein team inhuren dat onder jouw aansturing werkt. Dat past bij organisaties met een eigen IT afdeling en een duidelijk plan. Wie zoekt op softwareleverancier kiezen of software bedrijf, komt alle drie de vormen tegen; de vragen hieronder gelden vooral voor maatwerkbureaus.
Twijfel je nog of maatwerk de juiste route is, lees dan eerst wat maatwerk software is en wanneer standaardsoftware volstaat. Een eerlijke afweging vooraf bespaart maanden.
Negen vragen om een softwarebedrijf te kiezen
Stel deze vragen aan elk bureau op je shortlist en schrijf de antwoorden letterlijk op. Het verschil tussen bureaus zit zelden in de presentatie en bijna altijd in de details van de antwoorden.
1. Wie bouwt de software en wie beheert hem straks?
Vraag naar namen en rollen. Bij veel bureaus bouwt een projectteam de software, waarna een aparte beheerafdeling of een onderaannemer het overneemt. Elke overdracht kost kennis die jij later opnieuw betaalt. Het beste antwoord is dat de mensen die bouwen ook het onderhoud doen, of op zijn minst in hetzelfde team blijven.
2. Welke vergelijkbare projecten hebben ze opgeleverd?
Vraag om twee of drie cases die lijken op jouw opgave: dezelfde sector, hetzelfde soort koppelingen, een vergelijkbare omvang. Een bureau dat vooral webshops bouwt kan ook een planningssysteem voor de zorg maken, alleen leert het dan op jouw kosten. Let erop of de case een meetbaar resultaat noemt in plaats van alleen een mooi scherm.
Marieke, hoofd bedrijfsvoering bij een zorgorganisatie met 300 medewerkers, vroeg vijf bureaus om een referentieproject in de zorg. Twee stuurden een brochure, twee gaven de naam en het telefoonnummer van een klant, en één nodigde haar uit om een sprintdemo bij een lopend project bij te wonen. Die laatste drie kwamen op haar shortlist.
3. Hoe ziet het ontwikkelproces eruit?
Vrijwel elk bureau noemt zichzelf agile. Vraag daarom concreet hoe vaak je werkende software ziet, wie je vaste aanspreekpunt is en hoe wijzigingen in de scope worden besproken. Een goed antwoord bevat cycli van twee tot drie weken met een demo aan het eind, en een productowner aan jouw kant: iemand uit je eigen organisatie die de prioriteiten bepaalt.
4. Wie is eigenaar van de code?
Dit hoort zwart op wit in het contract: de broncode, de documentatie en de omgevingen zijn van jou zodra ze betaald zijn. Vraag ook of je al tijdens het project toegang krijgt tot de repository, de plek waar de code wordt bewaard. Een bureau dat de code afschermt tot de laatste factuur, maakt je afhankelijk op het moment dat je het minst kunt onderhandelen.
5. Hoe zit het met beveiliging en certificering?
ISO 27001 is de internationale norm voor informatiebeveiliging, ISO 9001 die voor kwaliteitsmanagement. Een certificaat bewijst dat processen beschreven, gecontroleerd en jaarlijks getoetst worden. Vraag daarnaast naar praktische zaken: hoe gaan ze om met productiedata, wie heeft toegang tot jouw omgeving en hoe houden ze de gebruikte bibliotheken bij. In de zorg en bij de overheid is dit vaak een harde eis.
Wil je zien hoe die antwoorden er in de praktijk uitzien, bekijk dan onze cases in zorg, industrie en luchtvaart.
6. Hoe schaalt het team op en af?
Een project heeft in de bouwfase soms vijf mensen nodig en in de beheerfase één. Vraag hoe het bureau dat opvangt: met eigen mensen, met freelancers of met een nearshoreteam. Bij nearshoring werkt een deel van het team vanuit een land dichtbij, in dezelfde tijdzone en met dezelfde werkwijze. Dat is een gangbare manier om te schalen zonder de aansturing te verliezen; in wat nearshoring is en wanneer het werkt lees je waar je dan op let.
7. Wat gebeurt er als een developer vertrekt?
Bas, IT manager bij een machinebouwer met 120 medewerkers, hoorde in maart dat de enige developer die zijn orderportaal kende, het bureau had verlaten. De documentatie bleek drie versies oud en er waren geen geautomatiseerde tests. Het duurde vier maanden voordat een opvolger de eerste wijziging durfde door te voeren.
Vraag daarom of er minimaal twee mensen aan jouw project werken, of een collega elke wijziging beoordeelt, of documentatie onderdeel van het werk is en of er tests draaien die een nieuwe developer houvast geven. Bureaus van elke omvang kunnen dit goed regelen, zolang de kennis van jouw software bij meer dan één persoon zit.
8. Hoe zit de offerte in elkaar?
Een goede offerte beschrijft de aannames, de scope per fase en wat erbuiten valt. Vraag hoe ze omgaan met werk dat vooraf niet in de scope stond, wat beheer en doorontwikkeling per jaar kosten en of je gefaseerd kunt starten met een eerste werkende versie. Een bedrag zonder aannames is een gok; de factoren achter dat bedrag lees je in wat maatwerk software kost.
9. Wat zeggen referenties?
Bel minstens twee klanten die langer dan een jaar met het bureau werken. Vraag naar de periode na de oplevering: reactietijd bij storingen, hoe wijzigingen verlopen en of het team nog hetzelfde is. Referenties uit het eerste projectjaar zijn bijna altijd positief; de jaren daarna vertellen het volledige verhaal.
Rode vlaggen bij het kiezen van een softwareleverancier
Bij deze drie signalen is doorvragen het minimum en afhaken vaak verstandiger:
- Een vaste prijs zonder uitgewerkte scope. Zonder gedeelde aannames betaalt een van beide partijen het verschil. Dat eindigt in discussies over meerwerk of in een bureau dat stilletjes bezuinigt op tests en documentatie.
- Geen toegang tot code en omgevingen tijdens het project. Je koopt dan een zwarte doos en ontdekt de kwaliteit pas bij oplevering, als bijsturen duur is.
- Alles loopt via één accountmanager. Spreek je de mensen die bouwen nooit, dan verdwijnt informatie in de overdracht en merk je misverstanden pas als de software staat.
Andere signalen die aandacht verdienen: cases zonder namen of cijfers, een team dat op elke wens ja zegt, en een offerte die binnen een dag na het eerste gesprek in je mailbox ligt.
Een vergelijkingstabel om zelf in te vullen
Zet de antwoorden van drie bureaus naast elkaar en geef per vraag een score van 1 tot 5. Weeg de eerste, vierde en zevende vraag het zwaarst: continuïteit, eigendom en kennisdeling bepalen hoe je er over vijf jaar voor staat. Een bureau dat daar laag scoort valt af, ook als de prijs aantrekkelijk is.
| Vraag | Bureau A | Bureau B | Bureau C |
|---|---|---|---|
| 1. Bouwers zijn ook beheerders | |||
| 2. Vergelijkbare cases met meetbaar resultaat | |||
| 3. Korte cycli met demo's | |||
| 4. Code en documentatie zijn van jou | |||
| 5. ISO 27001 of vergelijkbare aantoonbare beveiliging | |||
| 6. Schaalbaar team in dezelfde tijdzone | |||
| 7. Kennisdeling: twee mensen, reviews, tests | |||
| 8. Offerte met aannames en scope per fase | |||
| 9. Referenties ouder dan een jaar | |||
| Totaal |
Zo beantwoorden wij deze vragen zelf
Deze negen vragen krijgen wij zelf regelmatig; dit zijn onze antwoorden. De mensen die bij ons de software bouwen, zijn dezelfde mensen die hem daarna draaiend houden; dat is de kern van ons model. We werken in korte cycli met een demo aan het eind van elke cyclus, de code en de documentatie zijn eigendom van de opdrachtgever, en we zijn ISO 9001 en ISO 27001 gecertificeerd.
Opschalen doen we met ons eigen team van 30+ engineers in Nijmegen en Sarajevo, dat in de Nederlandse tijdzone en met dezelfde werkwijze werkt als de klant. Wie tijdelijk extra ontwikkelcapaciteit zoekt, kan ook engineers aan het eigen team toevoegen. In ruim dertig jaar en 100+ projecten in zorg, onderwijs, industrie, overheid en energie hebben we geleerd dat een eerlijk antwoord aan het begin de basis is voor een lange samenwerking, ook als dat antwoord is dat maatwerk voor jouw opgave geen goede route is.
Veelgestelde vragen
Wat is een softwarebedrijf?
Een softwarebedrijf ontwerpt, bouwt, levert en onderhoudt software. Productbedrijven ontwikkelen één pakket voor veel klanten, maatwerkbureaus bouwen software voor de processen van één organisatie. Beide vallen onder dezelfde term, en de keuze tussen die twee is de eerste stap bij softwareleverancier kiezen.
Wat is het verschil tussen een softwarebedrijf en een softwareontwikkelaar?
Een softwareontwikkelaar is een persoon die code schrijft, in loondienst of als freelancer. Een softwarebedrijf levert een team met meerdere rollen: ontwikkelaars, testers, een projectleider en vaak een architect of ontwerper. Voor een klein, afgebakend project kan één ontwikkelaar volstaan; zodra continuïteit, beheer en beveiliging tellen, biedt een bedrijf meer zekerheid.
Hoeveel offertes moet je aanvragen?
Drie is in de praktijk een goed aantal. Met minder mis je een referentiepunt, met meer verlies je tijd die je beter aan referentiechecks besteedt. Geef alle drie de bureaus dezelfde uitgangspunten en stel ze dezelfde negen vragen, anders vergelijk je appels met peren.
Waar let je op in een offerte voor maatwerksoftware?
Op de aannames, de scope per fase, wat erbuiten valt en hoe meerwerk wordt afgehandeld. Kijk ook naar de kosten van beheer en doorontwikkeling na oplevering, en naar de eigendomsbepaling voor code en documentatie. Een offerte die alleen een totaalbedrag en een opleverdatum noemt, geeft te weinig houvast.
Softwarebedrijf kiezen: de kernpunten
Een softwarebedrijf kiezen is vooral een keuze voor mensen en afspraken; de technologie volgt daarna. De kernpunten:
- Dezelfde mensen bouwen en beheren, zodat kennis blijft.
- Code, documentatie en omgevingen zijn van jou, ook tijdens het project.
- Korte cycli met demo's maken voortgang zichtbaar en bijsturen goedkoop.
- Certificering en kennisdeling beschermen je tegen vertrek en incidenten.
- Een offerte zonder aannames is een gok.
Maak nu een shortlist van drie bureaus, stel ze alle negen vragen en vul de tabel in. Wil je onze antwoorden op die vragen in een gesprek horen, plan dan een vrijblijvend gesprek. We zeggen het ook eerlijk als een ander type partner beter bij je opgave past.
