Second opinion voor software.

Waarom een second opinion?

Je hebt software laten bouwen door een externe partij. Of je zit midden in een traject en je hebt een onderbuikgevoel: klopt dit wel? Loopt het project niet te lang? Is de kwaliteit goed genoeg? Betaal ik een eerlijke prijs voor wat ik krijg?

Dat zijn geen rare vragen. Sterker nog, het zijn precies de juiste vragen. Software is een forse investering en de meeste opdrachtgevers missen de technische kennis om zelf te beoordelen of het goed gaat. Je vertrouwt op de partij die het bouwt, maar die heeft er belang bij om te zeggen dat alles prima loopt. Dat maakt een onafhankelijke blik waardevol.

Een second opinion is precies dat: een ervaren developer die geen belang heeft bij het project, maar wel naar de code kijkt, de architectuur beoordeelt en je eerlijk vertelt hoe het ervoor staat.

Wanneer vraag je een second opinion aan?

Er zijn een paar typische situaties waarin ondernemers bij mij aankloppen voor een onafhankelijke beoordeling:

Voor een grote investering

Je staat op het punt om tienduizenden euro's te investeren in een softwareproject. Een offerte van een bureau ligt op tafel, maar je wilt weten of de aanpak klopt, of de technologiekeuze logisch is en of de geschatte uren realistisch zijn. Een second opinion vooraf kan je duizenden euro's besparen door verkeerde keuzes vroeg te signaleren.

Tijdens een lopend project

Het project duurt langer dan gepland. De kosten lopen op. Je krijgt uitleg van de ontwikkelaar, maar je kunt niet inschatten of die uitleg klopt. Is het echt zo complex, of wordt er inefficiënt gewerkt? Een tussentijdse beoordeling geeft je grip op de situatie.

Na oplevering

De software is live, maar je merkt dat het traag is, dat er regelmatig bugs opduiken of dat nieuwe functionaliteit steeds meer kost. Je wilt weten of de basis goed is, of dat je op een wankel fundament verder bouwt.

Bij twijfel over je huidige partner

Je hebt het gevoel dat je huidige ontwikkelaar niet meer de juiste partij is, maar je weet niet zeker of dat terecht is. Misschien is de communicatie stroef, of heb je het idee dat de kwaliteit achteruitgaat. Een objectieve blik helpt je om die twijfel om te zetten in concrete feiten.

Wat beoordeel ik?

Een second opinion is geen vaag rapport met algemeenheden. Ik kijk concreet naar de volgende onderdelen:

• Codekwaliteit — Is de code leesbaar, consistent en goed gestructureerd? Wordt er gewerkt volgens gangbare standaarden? Of is het een lappendeken van quick fixes en workarounds?
• Architectuur — Past de gekozen opzet bij de schaal en complexiteit van het project? Is het gebouwd om door te groeien, of loop je straks tegen grenzen aan?
• Technische schuld — Hoeveel shortcuts zijn er genomen? En belangrijker: hoe erg is dat? Elke codebase heeft schuld, maar het verschil zit in de mate en de impact ervan.
• Beveiliging — Zijn de basisprincipes op orde? Denk aan authenticatie, autorisatie, inputvalidatie en omgang met gevoelige data. Geen pentest, maar een gezondheidscheck.
• Testbaarheid — Zijn er automatische tests? Kan de software betrouwbaar aangepast worden zonder dat alles breekt?
• Infrastructuur en deployment — Hoe wordt de software gehost en uitgerold? Is dat professioneel ingericht of met de hand in elkaar gezet?
• Onderhoudbaarheid — Kan een andere developer dit project overnemen? Of is alle kennis in het hoofd van één persoon die morgen weg kan zijn?

Hoe werkt het in de praktijk?

Het proces is bewust laagdrempelig gehouden. Geen ellenlange trajecten of dure voortrajecten.

Stap 1: Kennismaking

Een kort gesprek over je situatie. Wat is het project, waar zit je twijfel en wat wil je weten? Dit gesprek is vrijblijvend en kost je niets.

Stap 2: Toegang tot de code

Ik krijg leestoegang tot de broncode, bij voorkeur via een Git-repository. Ik bekijk alleen de code; ik wijzig niets en ik kopieer niets.

Stap 3: Beoordeling

Ik neem de codebase door en beoordeel de punten die hierboven staan. Afhankelijk van de omvang van het project kost dit één tot drie dagen.

Stap 4: Rapportage

Je ontvangt een helder rapport met mijn bevindingen. Geen jargon, geen wollig taalgebruik. Concrete observaties, duidelijke conclusies en praktische aanbevelingen. Wat is goed, wat kan beter en waar moet je je zorgen over maken?

Stap 5: Nabespreking

We bespreken het rapport samen. Ik leg alles uit in begrijpelijke taal en beantwoord je vragen. Als je wilt, kan ik ook meedenken over vervolgstappen.

Wat het niet is

Een second opinion is geen aanval op je huidige ontwikkelaar. Het is geen zoektocht naar fouten om iemand af te branden. Software bouwen is complex en er zijn altijd dingen die beter kunnen. Het doel is om je een eerlijk en genuanceerd beeld te geven, zodat je betere beslissingen kunt nemen.

Het is ook geen vervanging voor een volledige security-audit of pentest. Als dat nodig is, verwijs ik je door naar een gespecialiseerde partij. Wat ik wel doe, is de basis beoordelen en aangeven of een diepere audit noodzakelijk is.

Een second opinion is geen wantrouwen richting je ontwikkelaar. Het is zorgvuldigheid richting je investering.

Waarom ik?

Ik werk al meer dan vijftien jaar als software-developer en architect. Ik heb projecten gebouwd, overgenomen, gered en soms ook moeten afschrijven. Ik heb gezien wat er misgaat als er geen onafhankelijke controle is — en wat het oplevert als je dat wel doet.

Als solo-developer zonder commercieel belang bij het overnemen van je project, ben ik objectief. Ik heb geen team dat werk nodig heeft. Ik hoef je geen groot vervolgtraject te verkopen. Mijn enige belang is je een eerlijk beeld geven.

Heb je twijfels over je huidige softwareproject? Of wil je zekerheid voor je een grote investering doet? Neem contact op voor een vrijblijvend gesprek. Dat kost je niets behalve een half uur van je tijd — en het kan je duizenden euro's en maanden frustratie besparen.