Dienst · App-ontwikkeling

App second opinion — onafhankelijke audit en review.

Een vendor-onafhankelijke beoordeling van je bestaande app of in-development project. Codebase, architectuur, security en AVG, app-store-readiness, kosten-projectie, team- en leverancier-evaluatie en — sinds 2025 — AI Act-compliance. Senior NL-team, geen belang in continue-werk, geen tweekoppige sales-pitch. Een rapport waar je je raad van bestuur of investeerder mee onder ogen kunt komen.

Codebase-auditArchitectuurSecurity & AVGApp-store-readinessAI ActVendor-onafhankelijk

Plan een kennismaking Mail Fabian

Een second opinion is geen aanval op je huidige leverancier.

De meeste opdrachtgevers die ons bellen voor een second opinion zitten in een ongemakkelijke positie. Er is een app gebouwd, of er wordt nog gebouwd, en er zijn signalen dat het niet helemaal goed loopt: een release die telkens drie sprints uitloopt, een security-vraag van een grote klant die niet beantwoord raakt, een investeerder die voor de tech-due-diligence een onafhankelijke blik wil, een CTO die net is aangetreden en wil weten wat hij overneemt. Een gesprek met de huidige leverancier verloopt dan voorspelbaar — die heeft zelf belang bij doorbouwen — en intern is de kennis vaak te dun om de juiste vragen te stellen.

Dat is precies waar wij voor zijn. Wij hebben geen belang in het continue-werk: als de uitkomst van onze audit is dat je huidige leverancier prima werk levert en alleen wat scherper moet plannen, dan zeggen we dat. Als de uitkomst is dat de codebase zo zwak is dat een rebuild goedkoper is dan doorbouwen, zeggen we dat ook. We zijn senior NL-engineers met jaren mobile- en backend-ervaring, geen tweekoppige sales-pitch die zich tussendoor positioneert voor de vervolgopdracht. Onze brede app-praktijk staat los van de audit-praktijk — een opdrachtgever kan een second opinion afnemen zonder dat er ooit ander werk uit voortvloeit, en dat gebeurt regelmatig.

Voor founders die twijfelen aan hun huidige leverancier is een second opinion een manier om die twijfel om te zetten in een feitelijk besluit. Voor CTO's die net aangetreden zijn of die de stack moeten verantwoorden aan een board, is het een neutrale basis. Voor investeerders die tech-due-diligence laten doen, levert het de inhoudelijke laag onder een DD-proces — code-kwaliteit, technische schuld, vendor-afhankelijkheid en security-risico's in plaats van alleen een financieel en juridisch beeld. En voor ontwikkelteams die zelf willen weten of de kwaliteit waarop ze leveren marktconform is, geeft het een quality-gate die intern moeilijk te organiseren is.

De audit is altijd vertrouwelijk. We tekenen een NDA, we bewaren broncode en documentatie alleen voor de duur van het traject in een afgeschermde omgeving, en de rapportage gaat uitsluitend naar de opdrachtgever. Als je wil dat de huidige leverancier aanwezig is bij de eindbespreking — bijvoorbeeld om een gezamenlijk verbeterplan te maken — kan dat. Als je dat juist niet wil, ook prima.

Drie smaken second opinion.

De juiste vorm hangt af van wat je nodig hebt: een gerichte sanity-check, een volledige audit, of een tech-due-diligence voor een investerings- of overnamemoment. We adviseren in het eerste gesprek welke past — vaak begint een traject licht en groeit het door als er signalen zijn die opvolging verdienen.

Compact traject · vast sprintbudget

Sanity-check

Een gerichte review van een afgebakend deel van de app of het project. Geschikt als je een specifiek vermoeden hebt: "de release loopt steeds uit", "de inlog voelt traag", "we krijgen vragen over AVG die we niet kunnen beantwoorden". We kijken naar de codebase op het betreffende vlak, lopen door de architectuur, spreken een of twee key-engineers van het huidige team en leveren een kort rapport met findings, severity-classificatie en concrete adviezen.

Code-sampleArchitectuur-schetsFindings + severityBeknopt rapport

Middelgroot traject · vast sprintbudget

Volledige app-audit

Een complete second opinion over de app als geheel. We auditen de volledige codebase (iOS, Android, eventueel cross-platform via Flutter of React Native), de backend, de CI/CD-pipeline, de release-processen voor App Store en Google Play, de security- en AVG-positie en de operationele monitoring. Plus een evaluatie van het huidige team of de huidige leverancier op tempo, kwaliteit en kennisborging. Uitkomst: een gestructureerd rapport, findings per severity-niveau, een remediation-roadmap en — indien gewenst — een gesprek met het huidige team om het verbeterplan in te leiden.

Volledige codebaseArchitectuur-reviewSecurity & AVGRemediation-roadmap

Groter traject · vast sprintbudget

Tech-due-diligence

Een second opinion afgestemd op een investerings-, overname- of carve-out-moment. Naast de inhoud van de volledige audit ook een kosten-projectie voor doorontwikkeling en beheer, een vendor-risico-analyse (lock-in, key-person-dependency, contractuele clausules), een AI Act-compliance check als er AI-componenten in de app zitten, en een quality-gate-validatie tegen het type kopers- of investeerders-eisen die we kennen uit eerdere DD-trajecten. Rapport is opgesteld in een vorm die een investment-committee of acquisitie-team direct kan gebruiken.

Kosten-projectieVendor-risicoAI Act-complianceInvestor-ready rapport

Wat je krijgt aan het einde.

Een gestructureerd rapport waar je intern of extern mee verder kunt — voor een board-presentatie, voor een gesprek met je huidige leverancier of voor een investeerders-DD. Geen excel-dump met losse opmerkingen, maar een leesbaar document waar de severity, de remediation en de prioriteit duidelijk uit naar voren komen.

Gestructureerd rapportExecutive-summary voor de board of investeerder, plus een technische bijlage waarin elke finding wordt onderbouwd met code-referenties en context.
Findings met severity-classificatieElk gevonden risico ingedeeld op severity — kritiek, hoog, gemiddeld, laag, observatie — met onderbouwing en concreet remediation-voorstel per finding.
Remediation-roadmapEen geprioriteerde aanpak om de bevindingen op te lossen, ingedeeld in quick wins, structurele verbeteringen en strategische heroverwegingen — met realistische scope-indicatie per onderdeel.
Architectuur-overzichtVisueel diagram van de huidige architectuur (app, backend, externe afhankelijkheden, datastromen) zoals we die in de codebase aantroffen — vaak ontbreekt zo'n actueel beeld bij de opdrachtgever.
Security- en AVG-positieBeoordeling tegen OWASP MASVS en ASVS, een AVG-check op data-flows en grondslagen, en — waar relevant — een check tegen NEN 7510 (zorg) of ISO 27001-eisen die je klant of branche oplegt.
AI Act-compliance check (optioneel)Voor apps met AI-componenten een review tegen de relevante artikelen van de EU AI Act, met name Art. 9-15 voor risico-management, transparantie en menselijk toezicht.
Kosten-projectie doorontwikkelingEen realistische inschatting van wat het kost om de gevonden tekorten weg te werken en de app op een gezond niveau door te ontwikkelen, los van wie dat werk uitvoert.
Team- of leverancier-evaluatieEen feitelijke beoordeling van het huidige ontwikkelteam of de huidige leverancier op tempo, kwaliteit van levering, kennisborging en samenwerking — zonder waardeoordelen waar geen onderbouwing voor is.
Eindgesprek (optioneel met huidige leverancier)Een sessie waarin we de bevindingen toelichten — alleen met jou, met je interne team, of met je huidige leverancier aanwezig om gezamenlijk een verbeterplan op te stellen.

Wanneer een second opinion zinvol is.

Zes patronen die we keer op keer terugzien. Herken je je situatie in één ervan, dan praten we graag verder — ook als je nog niet zeker weet of een externe audit het juiste antwoord is.

Founder · twijfel

Twijfel aan huidige leverancier

De releases lopen telkens uit, de communicatie wordt gespannen, of er stapelen zich bugs op die niet structureel worden opgelost. Een onafhankelijke audit geeft helderheid: ligt het aan de scope, aan het team, aan de codebase of aan een combinatie? Met dat antwoord kun je een feitelijk gesprek met je leverancier voeren in plaats van een gevoels-gesprek dat nergens landt.

CTO · take-over

Nieuwe CTO of tech-lead

Je bent net aangetreden en moet binnen drie maanden aan de board uitleggen wat je hebt overgenomen — hoe staat de codebase ervoor, welke technische schuld zit erin, welke risico's lopen we op security en compliance, en wat zou een gezonde doorontwikkel-route zijn. Een externe audit geeft je dat beeld zonder dat je intern alle hete hangijzers zelf moet aanwijzen.

Investeerder · DD

Tech-due-diligence voor investering

Een VC of strategische koper laat een DD doen op een target met een app als kernproduct. Naast de financiële en juridische DD is er een inhoudelijke tech-laag nodig: code-kwaliteit, schaalbaarheid, technische schuld, key-person-dependency en vendor-risico. Wij leveren die laag in een vorm die direct in het DD-dossier past.

Pre-launch · quality-gate

Quality-gate voor launch

De app staat op het punt naar productie te gaan, maar je wil voor de launch een onafhankelijke check op security, performance, app-store-readiness en operationele gereedheid. Geen extra ontwikkelaar in het team, maar een neutrale poort die zegt: dit is klaar voor productie, of: deze drie dingen moeten eerst opgelost worden. Aanvullend op de eigen kwaliteitsslag van je team.

Compliance · audit

Compliance- of security-vraag van een klant

Een enterprise-klant of regulator vraagt om aantoonbare security en compliance — een SOC 2-traject, een ISO 27001-audit, een DPIA voor een datalek-gevoelige use-case. Onze audit geeft je een uitgangspositie en een verbeterplan, zodat het externe traject niet met te veel verrassingen opent.

AI · review

AI-componenten in de app

Er zit een LLM-integratie, een eigen model, een agent-loop of een aanbevelings-algoritme in de app, en je wil weten of dat AI Act-conform is opgezet en of er praktische risico's zijn op privacy, prompt-injection, dataretention of hallucinatie-blootstelling. Vaak wordt deze review samen met onze AI-consultancy-praktijk uitgevoerd.

Hoe een second opinion-traject loopt.

Kennismaking en scoping

Een gesprek waarin we doornemen wat je situatie is, welke signalen je ziet en wat je hoopt te bereiken met de audit. We bespreken praktische zaken: welke vorm past (sanity-check, volledige audit of tech-DD), wat de scope van de codebase is, of de huidige leverancier op de hoogte is en hoe vertrouwelijkheid wordt geregeld. Uitkomst: een afgebakende opdracht met een vaste prijs en planning, en een NDA als die nog niet ligt.

Toegang en kennismaking met materiaal

We krijgen lees-toegang tot de codebase (Git-repository), de architectuur-documentatie als die er is, de CI/CD-pipeline, monitoring-dashboards en eventueel bestaande security-rapporten. Voor in-development trajecten ook toegang tot het backlog en de sprint-rituelen. Indien gewenst spreken we een of twee key-engineers van het huidige team voor context — niet om over hen te oordelen, maar om de codebase sneller te kunnen lezen.

Audit-werk

De inhoudelijke fase. Statische code-analyse, handmatige review van kritieke modules, architectuur-walkthrough, dependency-scan, security-review tegen OWASP MASVS en ASVS, AVG-check op datastromen, evaluatie van de CI/CD-pipeline en de release-processen, AI Act-check waar van toepassing. Voor compliance-zwaar werk gebruiken we frameworks die aansluiten op je situatie — een fintech-app krijgt een andere lens dan een zorg-app, waarvoor we vaak ISO 27001-uitgangspunten en NEN 7510 erbij pakken.

Rapportage en remediation-roadmap

We stellen het rapport op met executive-summary, findings per severity, remediation-roadmap, kosten-projectie en — afhankelijk van de scope — vendor-risico-analyse en AI Act-bevindingen. Conceptversie bespreken we eerst met jou intern, zodat we feitelijke onjuistheden of context-missers kunnen corrigeren voordat het rapport definitief gaat. Voor security-context kun je onze gids over app-beveiliging als naslagwerk inzetten bij je interne team.

Eindbespreking

Een sessie waarin we de bevindingen mondeling toelichten — alleen met jou, met je interne team of, indien gewenst, met je huidige leverancier aanwezig. In dat laatste geval modereren we het gesprek zodat het constructief blijft en er aan het einde een concreet vervolgplan ligt waar beide partijen achter staan. Voor strategische vervolgvragen — moeten we de leverancier vervangen, moeten we inhouse gaan, moeten we de app rebuilden — kunnen we doorlopen in een digital-consulting-traject of laten we je los met een helder beeld.

Veelgestelde vragen.

Wat opdrachtgevers meestal willen weten voor we beginnen aan een second opinion.

Hoe blijft een second opinion echt onafhankelijk?

Door onze structuur en onze houding. Onze audit-praktijk staat los van onze app-bouwpraktijk: de senior engineer die jouw audit doet, heeft geen sales-target op een vervolgopdracht en wordt daarop ook niet beoordeeld. Daarnaast zijn we transparant over potentiële belangenconflicten: als we ooit eerder met de huidige leverancier hebben samengewerkt, of als we een directe concurrent van die leverancier zijn op andere klanten, melden we dat voordat de opdracht start. In de praktijk leidt de audit bij veel opdrachtgevers tot een verbeterplan met de huidige leverancier, niet tot een wisseling — dat is voor ons prima en feitelijk de meest voorkomende uitkomst.

Welke frameworks en standaarden gebruiken jullie?

Afhankelijk van de scope. Voor mobile-security standaard OWASP MASVS (Mobile Application Security Verification Standard) en ASVS voor het backend-deel. Voor algemene informatiebeveiliging ISO 27001 als kader. Voor zorg-apps NEN 7510 en de bijbehorende DPIA-eisen. Voor AI-componenten de relevante artikelen van de EU AI Act, met name Art. 9 (risico-management), Art. 10 (data-governance), Art. 13 (transparantie) en Art. 14-15 (menselijk toezicht en cybersecurity). Voor app-store-readiness de actuele richtlijnen van Apple App Store Review Guidelines en Google Play Policies — die updaten we per audit, want ze veranderen meerdere keren per jaar.

Wat hebben jullie nodig om te starten?

Lees-toegang tot de Git-repository met de app- en backend-code, eventuele architectuur-documentatie, toegang tot de CI/CD-omgeving (read-only is voldoende), inzage in de App-Store-Connect- en Google-Play-Console-accounts of een export daarvan, en — voor in-development trajecten — toegang tot het backlog en de laatste sprint-overzichten. Voor security-werk vragen we ook om eventuele eerdere pen-test-rapporten of security-audits, om dubbel werk te vermijden. Een NDA tekenen we voor het traject start; veel opdrachtgevers gebruiken ons NDA-template, anderen hun eigen.

Mag de huidige leverancier weten dat jullie kijken?

Dat bepaal jij. Sommige opdrachtgevers stellen hun leverancier open op de hoogte en vragen actief om medewerking — dat geeft ons toegang tot context die we anders moeten reverse-engineeren en versnelt het werk vaak. Andere opdrachtgevers willen de audit eerst stil houden, zeker in twijfel- of pre-investeringssituaties. Allebei werkt, met verschillende implicaties voor tempo en diepgang. In het kennismakingsgesprek bespreken we welke route bij jouw situatie past.

Kunnen jullie ook in-development trajecten auditen?

Ja, dat is een veelvoorkomende vraag. Bij een in-development audit kijken we niet alleen naar de code die er ligt, maar ook naar de backlog, de architectuur-keuzes die nog gemaakt worden, de sprint-cadans en de afspraken tussen jou en de leverancier. Vaak halen we vroege risico's eruit die anders pas later zichtbaar worden — een schaalbaarheids-keuze die op tien gebruikers werkt maar niet op tienduizend, een security-architectuur die niet bestand is tegen het type integratie dat aan komt, een release-pipeline die niet klaar is voor de eerste store-submission. Hoe eerder in het traject, hoe goedkoper de correctie.

Wat als jullie de huidige leverancier inderdaad zwak vinden?

Dan zeggen we dat, met onderbouwing per bevinding, en met een geprioriteerde lijst van wat moet veranderen om verder te kunnen. Soms is dat een verbetertraject met dezelfde leverancier — bijvoorbeeld een senior architect erbij, of een sprint-cadans-wijziging, of een quality-gate die we beschrijven. Soms is het een wissel of een hybride opstelling. Wij doen geen aanbeveling om jouw vervolgopdracht naar ons te trekken; we beschrijven wat er moet gebeuren en je kiest zelf wie het doet. In een aantal gevallen is de bevinding overigens dat de leverancier prima werk levert maar dat de scope of de communicatie het probleem is — ook dat zien we vaak.

Doen jullie ook pen-tests of certificeringen?

Pen-tests doen we niet zelf — daarvoor werken we samen met gespecialiseerde Nederlandse pen-test-bureaus die we al langer kennen. We kunnen er in de remediation-roadmap een opnemen, of de uitkomst van een eerdere pen-test integreren in onze audit. Certificeringen (ISO 27001, SOC 2, NEN 7510) lopen via geaccrediteerde auditors; wij leveren het voorbereidende werk en de remediation-aanpak waarmee een certificering haalbaar wordt — niet de certificering zelf. Dat is een bewuste scheiding zodat onafhankelijkheid behouden blijft.

Wat met AI Act-compliance in een app?

Voor apps met AI-componenten kijken we naar het risico-niveau van de toepassing (verboden, hoog-risico, beperkt-risico of minimaal risico onder de AI Act), de inrichting van risico-management volgens Art. 9, de data-governance volgens Art. 10, de transparantie-vereisten richting eindgebruikers volgens Art. 13 en de eisen voor menselijk toezicht en cybersecurity volgens Art. 14-15. Voor een aanbevelings-app in een retail-context ligt dat anders dan voor een diagnose-ondersteunende app in de zorg — we bepalen het toepasselijke regime per use-case. Voor de strategische kant van AI-keuzes verwijzen we vaak door naar onze AI-consultancy.

Werken jullie ook voor partijen buiten Nederland?

Voornamelijk werken we voor opdrachtgevers in Nederland en de Benelux, omdat we hechten aan korte fysieke afstand voor de eindbespreking en eventuele on-site sessies. Voor pan-Europese opdrachtgevers met een Nederlandse entiteit doen we wel audits — onze rapporten leveren we in het Nederlands of in het Engels, afhankelijk van wie hem leest. Voor opdrachten volledig buiten de EU verwijzen we door naar partners die daar gespecialiseerd in zijn.

Wie zit aan tafel bij de eindbespreking?

In de basis: jij, of de stakeholder die de audit heeft aangevraagd. Als je je interne team erbij wil — CTO, lead-engineer, product-owner — uiteraard. Als je de huidige leverancier erbij wil voor een gezamenlijk verbeterplan, kan dat ook; we modereren dat gesprek dan zodat het constructief verloopt. Voor investeerders-DD's zit vaak een investment-committee mee, of een deal-team. We passen de toon van de bespreking aan op het gezelschap — een gesprek met techniek-mensen ziet er anders uit dan een gesprek met een board.

Praat met ons over jouw second opinion.

Een kennismaking van een half uur, vrijblijvend. Vertel wat er speelt — de signalen waar je je zorgen om maakt, de stakeholder die het rapport gaat lezen, of de scope van de app die we tegen het licht moeten houden. We denken mee, geven richting en zijn eerlijk over of een second opinion in jouw situatie de juiste eerste stap is, of dat je eigenlijk een ander soort gesprek nodig hebt. Liever direct mailen kan ook bij fabian.vandijk@appfront.nl, of bekijk onze andere app-ontwikkeling-dienstpagina's voor verwante mobiele oplossingen.

Plan een kennismaking Of bekijk meer cases