Cyber Resilience Act · eenvoudig uitgelegd

CRA komt eraan. Goede software begint er vandaag al aan.

Vanaf 11 september 2026 gelden de eerste meldverplichtingen van de Cyber Resilience Act.
Vanaf 11 december 2027 wordt het grootste deel van de CRA van toepassing.

Dat klinkt nog ver weg.
Voor software is het dat niet.

Want CRA gaat niet alleen over wat je doet wanneer er iets misloopt. Het gaat ook over hoe software wordt gebouwd, welke componenten erin zitten, hoe je updates opvolgt en wat er gebeurt wanneer morgen een kwetsbaarheid wordt ontdekt.

Je hoeft daarvoor geen jurist te worden.
Je moet wel weten wat er in je software zit.

11 september 2026

De CRA-meldplicht start

Voor bepaalde actief uitgebuite kwetsbaarheden en ernstige beveiligingsincidenten.

11 december 2027

De meeste CRA-verplichtingen gelden

Security wordt nog nadrukkelijker een onderdeel van de volledige levenscyclus van software.

Wat is de Cyber Resilience Act eigenlijk?

De Cyber Resilience Act, kortweg CRA, is Europese regelgeving voor producten met digitale elementen.
Software kan daar dus onder vallen.

Europa wil daarmee iets wat eigenlijk vrij logisch klinkt: digitale producten moeten niet alleen werken wanneer ze op de markt komen. Er moet ook nagedacht worden over beveiliging, kwetsbaarheden, updates en ondersteuning tijdens hun verdere levensduur.

Dat verandert de vraag.

Niet alleen:

Werkt de software?

Maar ook:

Weten we wat erin zit? Kunnen we ze onderhouden? Kunnen we een kwetsbaarheid oplossen? En weten we wat we moeten doen als er iets gebeurt?

Dat laatste is minstens even belangrijk.

Een applicatie is niet klaar omdat ze live staat.

Frameworks veranderen.
Packages krijgen updates.
API's wijzigen.
Nieuwe kwetsbaarheden worden ontdekt.
Gebruikers komen en gaan.
Rechten veranderen.

En soms blijkt iets wat gisteren perfect normaal leek vandaag toch een beveiligingsprobleem.

Goede software moet daarmee kunnen omgaan.

Geldt de CRA voor jouw software?

Misschien.
En dat is bewust geen stoer marketingantwoord.

Of de CRA van toepassing is, hangt onder meer af van wat je precies aanbiedt, hoe het beschikbaar wordt gesteld en welke rol jouw organisatie daarin speelt.

Een interne bedrijfsapplicatie is niet automatisch hetzelfde als software die als product op de Europese markt wordt aangeboden.

En bij SaaS en cloudtoepassingen kan bijvoorbeeld de rol van zogenaamde remote data processing belangrijk worden.

Daarom zouden wij nooit op basis van één zin zeggen:

“Ja, jouw software valt onder CRA.”

Of:

“Nee, voor jou is er niets aan de hand.”

Eerst kijken wat er werkelijk gebouwd is.
Dat werkt meestal beter dan gokken.

Je ontwikkelt of verkoopt software

Dan kan CRA rechtstreeks relevant zijn en moet onder meer duidelijk zijn welke rol je als fabrikant hebt.

Je laat software bouwen

Dan moet duidelijk zijn wie welke rol en verantwoordelijkheid draagt. Wie bouwt? Wie onderhoudt? Wie volgt kwetsbaarheden en updates op? En wat gebeurt er wanneer er na de oplevering iets misloopt?

Je hebt een interne toepassing

Een interne toepassing valt niet automatisch onder dezelfde regels als een digitaal product dat op de markt wordt aangeboden.

Dat betekent niet dat de technische vragen rond security plots verdwijnen.

Je werkt met SaaS of cloudsoftware

Ook daar is een simpel ja of nee meestal te kort door de bocht. De concrete functie, architectuur en manier waarop de dienst met het digitale product verbonden is, zijn mee bepalend.

Niet zeker waar jouw software thuishoort?

Vertel ons wat ze doet en hoe ze gebruikt wordt.

Wij kunnen de technische kant mee uitklaren. Voor een definitieve juridische kwalificatie kan gespecialiseerd juridisch advies nodig zijn.

Leg je applicatie aan ons voor

Geen paniek. Wel beginnen.

CRA voorbereiden in 10 praktische stappen

Je wordt niet op een namiddag “CRA compliant” door tien vinkjes aan te kruisen.
Was het maar zo eenvoudig.

Wat je wél kunt doen: zorgen dat je software technisch begrijpbaar, beheersbaar en onderhoudbaar is.

Daar kun je vandaag mee beginnen.

Veel van deze punten zul je herkennen uit onze Safety First-aanpak. Dat is geen toeval. Goede securitypraktijken worden niet plots belangrijk omdat er nieuwe regelgeving komt.

01 — Weet wat je eigenlijk gebouwd hebt

Dat klinkt nogal vanzelfsprekend.

In de praktijk is dat het verrassend vaak niet.

  • Welke applicaties zijn er?
  • Waar draaien ze?
  • Welke data gebruiken ze?
  • Met welke API's praten ze?
  • Welke externe diensten zijn gekoppeld?
  • Wie gebruikt ze?
  • Wie beheert ze?
  • En wie is verantwoordelijk wanneer er iets fout loopt?

Voor je over security, CRA of kwetsbaarheden praat, moet het antwoord op die vragen duidelijk zijn.

Je kunt software moeilijk beschermen als niemand het volledige plaatje kent.

02 — Weet wat erin zit

Moderne software bestaat nooit alleen uit code die je zelf geschreven hebt.

Er zitten frameworks, libraries, packages, SDK's, API's en andere componenten in.

Dat is normaal.

Maar je moet ze wel kennen.

Want als morgen blijkt dat versie X van een gebruikte library een ernstige kwetsbaarheid heeft, wil je niet eerst drie dagen zoeken of die ergens in jouw applicatie zit.

Daarom wordt ook een SBOM — Software Bill of Materials belangrijker.

Zie het als een ingrediëntenlijst van je software.

Geen sexy document.

Wel bijzonder handig als er iets fout blijkt te zijn.

Wat je niet kent, kun je ook niet gericht updaten.

03 — Bouw security erin. Plak ze er niet achteraf op.

Security is geen knop die je vlak voor de lancering nog even aanzet.

Ze zit in keuzes die veel vroeger gemaakt worden.

  • Hoe logt iemand in?
  • Welke data mag die persoon zien?
  • Wat gebeurt er met foutieve input?
  • Waar bewaren we secrets en API-keys?
  • Wat kan standaard wel en niet?
  • Wat gebeurt er als iemand probeert iets te doen waarvoor hij geen rechten heeft?

Dat zijn architectuurvragen.

Niet alleen securityvragen.

Security achteraf toevoegen is meestal duurder, moeilijker en minder elegant dan er vanaf het begin rekening mee houden.

04 — Geef mensen alleen toegang tot wat ze nodig hebben

Niet iedere gebruiker hoeft alles te zien.

Niet iedere medewerker hoeft beheerder te zijn.

En een API hoeft ook niet meer rechten te krijgen dan ze nodig heeft.

Dat klinkt logisch.

Toch groeien rechten in applicaties na verloop van tijd gemakkelijk scheef.

Iemand krijgt tijdelijk toegang.

Een functie verandert.

Een integratie wordt uitgebreid.

En vijf jaar later weet niemand nog waarom account X alles mag.

Werk daarom bewust met gebruikers, rollen en rechten.

En hou het begrijpbaar.

“Iedereen admin” is geen rechtenmodel.

05 — Zorg dat je kunt terugkijken

Als iets misloopt, is:
“Er is iets fout gegaan.”
niet bijzonder nuttig.

Je wilt kunnen reconstrueren wat er gebeurd is.

  • Wanneer?
  • Bij welke actie?
  • Door welke gebruiker of welk systeem?
  • Wat ging eraan vooraf?
  • Welke fout kwam terug?

Daarvoor heb je goede logging nodig.

Niet alles loggen omdat het kan.

Wel loggen wat je nodig hebt om problemen, belangrijke wijzigingen en beveiligingsgebeurtenissen te begrijpen.

En uiteraard zonder daardoor zelf onnodig gevoelige gegevens te verzamelen.

Een goede log vertelt wat er gebeurde. Niet alleen dát er iets gebeurde.

06 — Hou je dependencies in leven

Een applicatie die vandaag veilig gebouwd is, blijft niet vanzelf veilig.

De wereld rondom die applicatie verandert.

Libraries worden bijgewerkt.

Frameworks krijgen security patches.

Versies raken buiten ondersteuning.

Nieuwe kwetsbaarheden worden gepubliceerd.

Daarom moet duidelijk zijn:

  • welke dependencies gebruikt worden
  • hoe securitymeldingen opgevolgd worden
  • wie beoordeelt of een update nodig is
  • wie zo'n update uitvoert
  • en hoe snel dat moet kunnen.

Een applicatie bouwen en ze daarna vijf jaar niet meer aanraken is geen onderhoudsstrategie.

Software veroudert ook als niemand eraan komt.

07 — Zet een naam naast verantwoordelijkheid

“IT zal dat wel bekijken” is geen proces.

Wanneer er een kwetsbaarheid of ernstig incident opduikt, moet iemand weten dat hij aan zet is.

  • Wie ontvangt de melding?
  • Wie beoordeelt hoe ernstig ze is?
  • Wie kijkt welke systemen geraakt zijn?
  • Wie beslist over een patch?
  • Wie communiceert?
  • Wie documenteert wat er gebeurd is?
  • En wie controleert of er een CRA-melding nodig is?

Dat hoeft in een kmo geen comité van twaalf personen te zijn.

Eén duidelijke naam is al een uitstekend begin.

Een probleem zonder eigenaar blijft meestal langer een probleem.

08 — Bedenk op voorhand wat je doet als er iets gebeurt

Een incidentplan hoeft geen map van 187 pagina's te zijn die ergens op SharePoint stof verzamelt.

Het moet vooral bruikbaar zijn.

In de praktijk wil je weten:

  1. wat is er gebeurd?
  2. wat is geraakt?
  3. hoe beperken we de schade?
  4. hoe lossen we het op?
  5. wie moet dit weten?
  6. wat moeten we bewaren en documenteren?
  7. moeten we dit melden?

Als je daar voor het eerst over nadenkt terwijl er effectief iets misloopt, ben je te laat begonnen.

Een eenvoudig plan dat iedereen kent is nuttiger dan een perfect plan dat niemand vindt.

09 — Ken de meldplicht vóór je ze nodig hebt

Vanaf 11 september 2026 gelden de CRA-meldverplichtingen.

Voor fabrikanten gaat het daarbij onder bepaalde voorwaarden om actief uitgebuite kwetsbaarheden en ernstige incidenten die gevolgen hebben voor de beveiliging van een product met digitale elementen.

Dus niet ieder foutje.

Niet iedere bug.

Niet iedere mislukte login.

Maar wanneer een gebeurtenis wél onder de meldplicht valt, zijn de termijnen kort.

Daarom moet je dit proces kennen vóór er iets gebeurt.

24 uur is behoorlijk kort als je eerst nog moet uitzoeken wie verantwoordelijk is.

  1. Zodra je je bewust wordt van een meldingsplichtige gebeurtenis

    De klok begint te lopen.

  2. Binnen 24 uur

    Vroegtijdige waarschuwing

    Een eerste melding.

    Het doel is snel signaleren dat er een relevante gebeurtenis is.

  3. Binnen 72 uur

    Verdere melding

    Er volgt een uitgebreidere melding met de informatie die op dat moment beschikbaar is.

  4. Daarna

    Eindrapport

    Bij een actief uitgebuite kwetsbaarheid moet het eindrapport uiterlijk 14 dagen nadat een corrigerende of mitigerende maatregel beschikbaar is worden ingediend.

    Bij een ernstig beveiligingsincident geldt een termijn van één maand na de 72-uursmelding.

De officiële CRA-regels en meldprocedure blijven uiteraard leidend.

10 — Denk verder dan de dag van oplevering

Dit is misschien de belangrijkste.

Software is niet klaar omdat ze online staat.

Na de lancering begint gewoon een andere fase.

Er komen nieuwe gebruikers.

Processen veranderen.

Er worden koppelingen toegevoegd.

Dependencies evolueren.

Securityproblemen worden ontdekt.

Regelgeving verandert.

En iemand moet de applicatie ondertussen blijven begrijpen.

Daarom horen onderhoud, updates en security voor ons bij de architectuur van software.

Niet alleen bij een onderhoudscontract dat na de oplevering ergens in een lade verdwijnt.

Goede software moet niet alleen vandaag werken. Je moet er morgen nog veilig aan durven komen.

Hoe wij daar zelf mee omgaan

Daarom bestaat het BUSTER Framework

Niet omdat iedere applicatie hetzelfde is.
Net omdat niet ieder project alles opnieuw hoeft uit te vinden.

Als we maatwerk bouwen, bouwen we wat specifiek is voor jouw bedrijf ook echt op maat.

Maar een login?
Gebruikers?
Rollen en rechten?
Logging?
Configuratie?
API-patronen?
Foutafhandeling?

Een aantal technische vraagstukken komt in bijna iedere bedrijfsapplicatie terug.

Daar willen we niet bij ieder project opnieuw vanaf een wit blad over beginnen nadenken.

Daarvoor hebben we het BUSTER Framework.
Onze gekende technische basis waarop we maatwerkapplicaties bouwen.

Een gekende basis

We weten hoe belangrijke onderdelen opgebouwd zijn en waar ze zitten.

Dat maakt een applicatie later veel makkelijker te begrijpen.

Minder eenmalige oplossingen

Niet ieder project krijgt voor dezelfde fundamentele problemen opnieuw een andere oplossing.

Minder improvisatie betekent minder verrassingen.

Onderhoud wordt realistischer

Als een applicatie na twee of drie jaar aangepast moet worden, willen we niet eerst archeoloog spelen in onze eigen code.

We kunnen gerichter bijwerken

Een gekende technische basis maakt het eenvoudiger om gemeenschappelijke onderdelen te verbeteren en veranderingen systematisch te benaderen.

Minder improvisatie. Meer controle.

Dat is voor ons de echte waarde van een framework.

Niet zoveel mogelijk standaardiseren.
Wel weten waarop je bouwt.

Want hoe belangrijker software wordt voor een bedrijf, hoe belangrijker het wordt dat iemand ze later nog begrijpt.

Wat we hier niet beweren

Het BUSTER Framework maakt een applicatie niet automatisch CRA-conform.
Geen enkel framework kan dat op zichzelf.

CRA gaat over veel meer dan code: het concrete product, de rol van de fabrikant, risicoanalyse, processen, documentatie, vulnerability handling, ondersteuning en andere verplichtingen spelen allemaal mee.

Wat een gekende technische basis wél doet?

Ze maakt het makkelijker om software systematisch te bouwen, te begrijpen, te onderhouden en aan te passen.

Dat vinden we een veel geloofwaardiger verhaal dan een sticker met “CRA-proof” erop.

Meer over het BUSTER Framework

Bekijk ook hoe Ghostbuster breder naar softwareveiligheid kijkt

Wij bouwen liever software waar we later nog aan durven komen.

Een applicatie is voor ons geen verzameling schermen die op de dag van oplevering toevallig doet wat er in de offerte stond.

We willen ook weten wat er daarna gebeurt.

Wie onderhoudt ze?
Welke componenten zitten erin?
Hoe zijn rechten geregeld?
Waar zien we wat fout ging?
Wat gebeurt er wanneer een externe API verandert?
Kunnen dependencies bijgewerkt worden?
En wat doen we wanneer ergens een ernstige kwetsbaarheid wordt ontdekt?

CRA maakt een aantal van die vragen nu explicieter.

Maar eigenlijk zijn het vragen die een softwarebouwer sowieso hoort te stellen.

Goede software begint niet met code.

Ze begint met begrijpen wat een bedrijf nodig heeft.

Waar informatie vandaan komt.
Wie ermee werkt.
Welke systemen met elkaar moeten praten.
Wat fout kan lopen.
En wat er over drie jaar nog moet kunnen veranderen.

Daarna komt de code.

Dat is ook waarom we bij Ghostbuster veel werken met:

Niet omdat techniek het doel is.

Omdat software pas nuttig wordt wanneer ze in de echte werking van een bedrijf past.

Heb je al software?
Begin dan niet met het woord “compliance”.

Begin met kijken.

  • Wat draait er vandaag?
  • Welke technologie wordt gebruikt?
  • Welke dependencies zitten erin?
  • Wie kan wat?
  • Welke API's en externe diensten zijn gekoppeld?
  • Wat wordt gelogd?
  • Hoe gebeuren updates?
  • Wie onderhoudt de toepassing?
  • En wat gebeurt er wanneer morgen een kritieke kwetsbaarheid opduikt?

Met die antwoorden heb je veel meer aan te vangen dan met een checklist waarop overal voorlopig “onbekend” staat.

Waar kunnen wij bij helpen?

Wij zijn softwarebouwers.
Geen advocatenkantoor.

Onze rol zit dus vooral aan de technische kant.

We kunnen bijvoorbeeld samen kijken naar:

  • de architectuur van een bestaande applicatie
  • gebruikte componenten en dependencies
  • authenticatie, gebruikers, rollen en rechten
  • logging en foutafhandeling
  • API's en externe koppelingen
  • update- en onderhoudsprocessen
  • technische documentatie
  • vulnerability handling
  • de manier waarop incidenten technisch opgevolgd kunnen worden
  • de onderhoudbaarheid van de toepassing.

En soms is de conclusie:
hier zit het goed.

Dat zeggen we dan ook.

Je hoeft geen project te verzinnen om een checklist gevuld te krijgen.

Leg je applicatie eens op tafel.

Je hoeft ons geen dossier van vijftig pagina's te sturen.

Vertel gewoon:

  • wat je software doet
  • wie ze gebruikt
  • hoe belangrijk ze is voor je werking
  • waar ze draait
  • en wie ze vandaag onderhoudt.

Dan kunnen we samen bekijken waar de eerste technische vragen zitten.

En waar je vooral géén tijd aan moet verliezen.

Veelgestelde vragen over de Cyber Resilience Act

Wat is de Cyber Resilience Act?

De Cyber Resilience Act, of CRA, is Europese regelgeving met cybersecurityvereisten voor producten met digitale elementen. Daar kan ook software onder vallen.

De regels gaan niet alleen over beveiliging op het moment dat een product op de markt komt. Ook onderwerpen zoals kwetsbaarheden, beveiligingsupdates, ondersteuning en incidentmeldingen spelen een rol tijdens de verdere levensduur van het product.

Vanaf wanneer geldt de Cyber Resilience Act?

De CRA trad op 10 december 2024 in werking.

De meldverplichtingen van artikel 14 worden van toepassing op 11 september 2026.

Het grootste deel van de overige verplichtingen wordt van toepassing op 11 december 2027.

Wat verandert er op 11 september 2026?

Vanaf 11 september 2026 moeten fabrikanten onder de CRA bepaalde actief uitgebuite kwetsbaarheden en ernstige beveiligingsincidenten melden.

Voor gebeurtenissen die onder die meldplicht vallen, gelden korte termijnen. Daarom is het verstandig om vooraf te weten wie een melding beoordeelt en wie actie onderneemt.

Moet ieder beveiligingsprobleem binnen 24 uur gemeld worden?

Nee.

De CRA-meldplicht gaat niet over iedere bug of ieder technisch probleem.

Ze heeft onder meer betrekking op actief uitgebuite kwetsbaarheden en ernstige incidenten die gevolgen hebben voor de beveiliging van het product, wanneer aan de voorwaarden uit de CRA voldaan is.

Wat moet binnen 24 uur gebeuren?

Voor een meldingsplichtige gebeurtenis moet een fabrikant binnen 24 uur nadat hij zich ervan bewust is geworden een vroegtijdige waarschuwing indienen.

Dat is een eerste snelle melding. De uitgebreidere informatie volgt daarna.

Wat gebeurt er binnen 72 uur?

Binnen 72 uur volgt voor een meldingsplichtige gebeurtenis een uitgebreidere melding met de informatie die op dat moment beschikbaar is.

Daarna kan nog een eindrapport vereist zijn.

Wanneer moet het eindrapport ingediend worden?

Bij een actief uitgebuite kwetsbaarheid moet het eindrapport uiterlijk 14 dagen nadat een corrigerende of mitigerende maatregel beschikbaar is worden ingediend.

Bij een ernstig beveiligingsincident geldt een termijn van één maand na de 72-uursmelding.

Voor een concrete melding blijven de officiële CRA-regels en procedures uiteraard bepalend.

Geldt CRA ook voor software?

Ja, software kan een product met digitale elementen zijn en dus binnen het toepassingsgebied van de CRA vallen.

Dat betekent niet dat iedere website, interne applicatie of online dienst automatisch onder exact dezelfde verplichtingen valt. De concrete situatie en de rol van de betrokken onderneming zijn belangrijk.

Geldt de CRA voor SaaS?

Niet iedere SaaS-dienst valt automatisch op dezelfde manier onder de CRA.

De CRA regelt op zichzelf geen diensten, maar zogenaamde remote data processing solutions die noodzakelijk zijn voor de werking van een product met digitale elementen kunnen wel deel uitmaken van de beoordeling.

Bij SaaS moet je dus naar de concrete architectuur en dienstverlening kijken.

Geldt de CRA voor maatwerksoftware?

Maatwerksoftware is niet automatisch vrijgesteld of automatisch onderworpen aan alle CRA-verplichtingen.

Onder meer de manier waarop de software wordt aangeboden, de commerciële context en de rol van de betrokken partijen zijn belangrijk.

Daarom is een concrete beoordeling nodig.

Geldt de CRA voor software die we alleen intern gebruiken?

Een interne bedrijfsapplicatie is niet automatisch hetzelfde als een product met digitale elementen dat op de Europese markt wordt aangeboden.

Of CRA-verplichtingen spelen, hangt af van de concrete situatie.

Los daarvan blijven onderwerpen zoals rechten, updates, dependencies en vulnerability management ook voor interne bedrijfskritische software verstandig.

Wat betekent secure by design?

Secure by design betekent dat beveiliging al tijdens analyse, architectuur en ontwikkeling wordt meegenomen.

Dus niet eerst een applicatie bouwen en vlak voor de lancering proberen beveiliging eraan toe te voegen.

Denk bijvoorbeeld aan authenticatie, rechten, veilige standaardinstellingen, inputvalidatie, secrets, dataflows en foutafhandeling.

Wat is een SBOM?

SBOM staat voor Software Bill of Materials.

Je kunt het zien als een ingrediëntenlijst van software: welke componenten, libraries en andere dependencies worden gebruikt?

Dat helpt bijvoorbeeld om sneller te bepalen of een nieuw ontdekte kwetsbaarheid relevant is voor jouw applicatie.

Wat is vulnerability management?

Vulnerability management is het proces waarmee je kwetsbaarheden opspoort, beoordeelt, opvolgt en waar nodig oplost.

Dat betekent onder meer weten welke softwarecomponenten je gebruikt, security-informatie opvolgen, risico's beoordelen en updates of patches kunnen uitvoeren.

Moet bestaande software aangepast worden voor CRA?

Dat kun je niet alleen op basis van de leeftijd van een applicatie bepalen.

De CRA bevat overgangsregels en het toepassingsgebied hangt af van de concrete situatie.

Technisch is het wel verstandig om bestaande belangrijke software nu al te inventariseren. Zeker wanneer niet duidelijk is welke dependencies gebruikt worden, hoe updates gebeuren of wie verantwoordelijk is voor beveiligingsproblemen.

Kan Ghostbuster onze software CRA-compliant maken?

Geen softwarebouwer kan op basis van alleen wat code geloofwaardig beloven dat een organisatie of product automatisch “CRA-compliant” is.

We kunnen wel helpen met de technische kant: architectuur, dependencies, rechten, logging, updates, onderhoudbaarheid, vulnerability handling en andere onderdelen van de softwarebasis.

Voor een formele juridische beoordeling kan bijkomend gespecialiseerd advies nodig zijn.

Is het BUSTER Framework CRA-compliant?

Een framework op zichzelf is niet “CRA-compliant”.

Het BUSTER Framework geeft ons wel een gekende technische basis waarmee we terugkerende onderdelen van bedrijfssoftware op een consistente manier kunnen bouwen en onderhouden.

Dat helpt om controle te houden.

Maar CRA-conformiteit hangt van veel meer af dan het gebruikte framework.

Wil je het liever uit de eerste hand lezen?

Terecht.

Voor regelgeving vertrouwen we liever op de bron dan op een blog die een blog over een andere blog heeft samengevat.

Gebruik onderstaande officiële bronnen:

Laatst inhoudelijk gecontroleerd: 29 augustus 2026

Deze pagina geeft een praktische technische toelichting en vormt geen juridisch advies. Of en hoe de Cyber Resilience Act op een specifieke organisatie, toepassing of product van toepassing is, hangt af van de concrete situatie.

Software wordt belangrijker. Dan mag de manier waarop ze gebouwd wordt dat ook worden.

Wij bouwen niet alleen voor de demo.
Niet alleen voor de lancering.
En niet alleen voor wat vandaag op de planning staat.

We bouwen liever software waarvan we ook later nog weten wat erin zit, waarom ze zo gebouwd is en hoe we eraan kunnen werken.

Dat is geen CRA-feature.
Dat is gewoon hoe wij vinden dat software gebouwd hoort te worden.

Praat met Ghostbuster

🍪 Wij gebruiken cookies om je ervaring te verbeteren. Door verder te gaan, ga je akkoord met ons cookiebeleid.