Je veilingmeester roept lot 47 af vanaf de vloer terwijl je WebSocket een bieding verstuurt — en vijftien ranchers vernieuwen tegelijk hun telefoon. Een livestream bevriest midden in de veiling. Iemands $12.000 veebieding bereikt nooit de server. In twee jaar het bouwen van real-time biedingssystemen, zijn veestapelveilingplatforms de moeilijkste beperkingen naar voren gekomen die ik heb uitgebracht: sub-seconde latentie over plattelandse 4G, gelijktijdige biedingen van fysieke vloer en externe gebruikers, HD-video die niet kan bufferen op een Montana ranch, en transacties waarbij een gemiste bieding tienduizenden dollars kost. De meeste veilingssoftware behandelt 'real-time' als een twee-seconden polling loop — veeveilers werken sneller dan dat. De tech stack die werkelijk werkt, is niet degene in de Next.js showcase repo's.

Maar het is ook een van de meest lonende builds. De veestapelveilingsindustrie is massaal — Superior Livestock Auction alleen behandelt jaarlijks meer dan 1,9 miljoen stuks — en de technologische marktleiders zijn rijp voor verstoring. DVAuction is al jaren de go-to, maar veel operators zoeken naar alternatieven die hun meer controle, betere marges en moderne UX geven.

Dit artikel is de gids die ik had willen hebben toen ik begon. We behandelen architectuur, videostreaming, de biedingsengine, en alle scherpe randen waar je jezelf aan zult snijden als je niet voorzichtig bent.

Inhoudsopgave

De veestapelveiling markt begrijpen

Voordat je een enkele regel code schrijft, moet je begrijpen wat "simulcast" in deze context werkelijk betekent. Het is niet alleen het streamen van video van een veiling. Het is het uitvoeren van een enkele, uniforme veiling waar biedingen tegelijkertijd van twee volledig verschillende kanalen binnenkomen: de fysieke verkoopschuurdeur en het internet.

De veilingmeester roept de verkoop af. Ringmannen spotten biedingen van ranchers op de tribunes. En tegelijkertijd plaatsen onlinebieders van over het hele land (of de wereld — LSL Auctions streamt dagelijks naar miljoenen kijkers wereldwijd) biedingen door op knoppen om biedingen in te dienen die in real-time naar de veilingmeester worden doorgegeven.

De cijfers vertellen het verhaal waarom dit uitmaakt:

Platform Schaal Model
Superior Livestock Auction 1,9M stuks/jaar, 49K+ stuks per evenement Studio-videoveilingen met livestream-biedingen
LiveAg 15.000 stuks in een enkel april 2026-evenement Landelijke inzending, Fort Worth Stockyards
LSL Auctions Miljoenen gelijktijdige kijkers dagelijks Zero-latentie simulcast in Ierland, VK, Spanje
Auctionmarts.com Actief in VK, Ierland, NZ, Noord-Amerika Live internet-biedingen met veilingmeestercommunicatie
CattleUSA Groeiend netwerk van Amerikaanse verkoopsschuren Live streamen met geluidsbiedingen

Dit zijn geen kleine aantallen. Een enkele partij vee kan voor $50.000 tot $500.000+ verkocht worden. Wanneer je met dat soort geld omgaat, is "goed genoeg" latentie niet goed genoeg.

Waarom operators DVAuction alternatieven willen

Ik heb met veilinghuizeigenaren gesproken die DVAuction en vergelijkbare platforms gebruiken. Hun klachten zijn consistent:

  1. Commissiestructuur — Ze betalen per-stuks of percentagekosten die hun marges eten
  2. Beperkte maatwerk — Hun merk staat op de achtergrond van het platform merk
  3. Technische beperkingen — Videokwaliteitsproblemen, bieding lag tijdens piekgebeurtenissen
  4. Dataeigendom — Ze bezitten hun koper-/verkoopersgegevens niet volledig
  5. Afhankelijkheid — Als het platform uitvalt, is hun hele verkoop dood

Het bouwen van je eigen platform (of het laten bouwen) lost al deze problemen op. Maar het introduceert complexiteit waar je voor klaar moet zijn.

Core-architectuur voor een simulcast veiling platform

Laten we over architectuur praten. Een veestapel simulcast platform heeft vijf grote subsystemen, en ze moeten allemaal in bijna-real-time met elkaar communiceren:

┌─────────────────────────────────────────────────┐
│                   CDN / Edge                      │
├──────────┬──────────┬──────────┬─────────────────┤
│  Video   │  Bidding │  Catalog │   Auth/Payment  │
│ Ingest & │  Engine  │   & Lot  │   Gateway       │
│ Delivery │ (WS/RT)  │   CMS    │                 │
├──────────┴──────────┴──────────┴─────────────────┤
│              Message Bus (Redis/Kafka)            │
├──────────────────────────────────────────────────┤
│          PostgreSQL + Object Storage (S3)        │
└──────────────────────────────────────────────────┘

De berichtbus is alles

Elk subsysteem communiceert via een berichtbus. Wanneer een bieding van de vloer binnenkomt, raakt het de bus. Wanneer een online bieding via WebSocket aankomt, raakt het de bus. De biedingsengine verbruikt van de bus, valideert en publiceert het resultaat terug.

Voor een MVP werkt Redis Pub/Sub prima. Je zult honderden gelijktijdige bieders aankunnen zonder ergens mee te hebben. Zodra je evenementen uitvoert met duizenden gelijktijdige bieders en meerdere gelijktijdige veilingen, wil je Kafka of NATS voor duurzaamheid en replay-mogelijkheid.

// Vereenvoudigde bieding-ereignissenstroom
interface BidEvent {
  lotId: string;
  bidderId: string;
  amount: number;
  source: 'floor' | 'online' | 'proxy';
  timestamp: number; // Unix ms
  auctionId: string;
}

// Publisher (van WebSocket handler)
await redis.publish('bids:incoming', JSON.stringify(bidEvent));

// Consumer (biedingsengine)
redis.subscribe('bids:incoming', async (message) => {
  const bid = JSON.parse(message);
  const result = await processBid(bid);
  await redis.publish('bids:accepted', JSON.stringify(result));
});

Real-Time biedingsengine ontwerp

Hier leven of sterven veilingen. Je biedingsengine moet drie soorten biedingen tegelijk aankunnen:

  1. Vloerbiedingen — Ingevoerd door een bediende die naar de veilingmeester kijkt, doorgegeven via een eenvoudige bediendinterface
  2. Online biedingen — Ingediend door geverifieerde gebruikers via de web-/mobiele UI via WebSocket
  3. Proxybiedingen — Vooraf ingestelde maximale biedingen die automatisch stijgen (zoals eBay's systeem)

Bieding validatiepijplijn

Elke bieding gaat door dezelfde pijplijn, ongeacht bron:

async function processBid(bid: BidEvent): Promise<BidResult> {
  const lot = await getLotState(bid.lotId);
  
  // 1. Is het partij momenteel actief?
  if (lot.status !== 'active') {
    return { accepted: false, reason: 'lot_not_active' };
  }
  
  // 2. Ligt de bieding boven de huidige hoogste bieding + minimale increment?
  const minNext = lot.currentBid + lot.increment;
  if (bid.amount < minNext) {
    return { accepted: false, reason: 'below_minimum' };
  }
  
  // 3. Is de bieder geverifieerd en vooraf geautoriseerd?
  const bidder = await getBidderStatus(bid.bidderId);
  if (!bidder.verified || !bidder.paymentAuthorized) {
    return { accepted: false, reason: 'bidder_not_authorized' };
  }
  
  // 4. Controleren op zelfbiedingen (shill bid preventie)
  if (bid.bidderId === lot.currentHighBidderId && bid.source !== 'proxy') {
    return { accepted: false, reason: 'already_high_bidder' };
  }
  
  // 5. Accepteren en atomaire status bijwerken
  await updateLotState(bid.lotId, {
    currentBid: bid.amount,
    currentHighBidderId: bid.bidderId,
    bidHistory: [...lot.bidHistory, bid],
  });
  
  // 6. Controleren en proxybiedingen activeren
  await checkProxyBids(bid.lotId, bid.amount);
  
  return { accepted: true, newHighBid: bid.amount };
}

Het kritieke punt hier: state updates moeten atomair zijn. Twee biedingen die binnen milliseconden van elkaar voor dezelfde partij binnenkomen, moeten in serie worden gezet. Ik gebruik Redis-transacties (MULTI/EXEC) of PostgreSQL advisory locks hiervoor. Probeer het niet met applicatieniveau mutexes — het schaalt niet.

Incrementtabellen

Veestapelveilingen gebruiken variabele bieding increments op basis van de huidige prijs. Een typische veestapelveiling incrementtabel ziet er als volgt uit:

Huidge biedingsbereik Minimale increment
$0 - $500 $10
$500 - $2.000 $25
$2.000 - $10.000 $50
$10.000 - $50.000 $100
$50.000+ $250

Maak deze configurabel per veiling of zelfs per partij. Verschillende verkoopsoorten (zaadstock versus voedervee versus fokkeiheifers) hebben verschillende prijsbereiken en biedingspatronen.

Live videostreaming die werkelijk werkt op het platteland

Hier is het ding dat niemand je vertelt: je gebruikers zijn ranchers. Veel van hen bieden vanuit pickups op plattelandswegen met vlekkerige 4G. LSL Auctions engineert specifiek hiervoor — ze beweren zero-latentie HD die op 4G in velden werkt, en dat is de lat waar je overheen moet gaan.

Protocolkeuze is belangrijk

Protocol Latentie Browserondersteuning Kosten
HLS 6-30 seconden Universeel Laag
DASH 3-10 seconden De meeste browsers Laag
WebRTC < 1 seconde Moderne browsers Gemiddeld
WHIP/WHEP < 1 seconde Groeiend Gemiddeld
LL-HLS 2-4 seconden Goed Laag

Voor simulcast veilingen is HLS latentie onaanvaardbaar. Op het moment dat een online bieder ziet dat de veilingmeester om een bieding vraagt, heeft iemand op de vloer al gewonnen. Je hebt minimaal sub-2-seconde latentie nodig.

Mijn aanbeveling: Gebruik WebRTC voor actieve bieders en LL-HLS voor toeschouwers. Actieve bieders (geregistreerd, betalingsvooraf geautoriseerd) krijgen de lage-latentie WebRTC stream. Iedereen anders kijkt op LL-HLS, wat goedkoper is om op schaal te leveren en geeft toch nog een aanvaardbare ervaring.

// Adaptieve kwaliteit op basis van verbinding
const streamConfig = {
  activeBidder: {
    protocol: 'webrtc',
    maxBitrate: 4000, // kbps
    fallback: 'll-hls',
    adaptiveBitrate: true,
    minBitrate: 500, // Nog steeds kijkbaar op 4G
  },
  spectator: {
    protocol: 'll-hls',
    qualities: ['1080p', '720p', '480p', '360p'],
    autoQuality: true,
  }
};

Streaminginfrastructuur

Kijk voor beheerde oplossingen naar:

  • Amazon IVS — Gebouwd voor interactief, lage latentie. ~$1,50/uur voor basiskanaal
  • Cloudflare Stream — Goede CDN-integratie, $1/1000 minuten geleverd
  • Ant Media Server — Zelf gehost optie, eenmalige licentie ~$2.399, geeft je volledige controle
  • Mux — Developer-friendly API, realtimestreams vanaf $0,025/min

Zelf hosten (Ant Media op je eigen infra) geeft je de meeste controle en kan op schaal goedkoper zijn, maar beheerde oplossingen zoals Mux of Amazon IVS verminderen de ops-last aanzienlijk.

Het catalogus- en lot-beheersysteem

Elke partij in een veestapelveiling heeft rijke media nodig: foto's, video's, gezondheidsgegevens, EPD-gegevens (Expected Progeny Differences voor zaadstock), gewichttickets, merkinspectiedocumenten en verkoopersinformatie.

Dit is in wezen een headless CMS-probleem. Als je op Next.js bouwt (wat ik zou aanbevelen voor de frontend — meer daarover in de stack sectie), een headless CMS zoals Sanity, Strapi, of Payload CMS behandelt de catalogus wunderbar.

Het inhoudsmodel ziet er in vereenvoudigde vorm als volgt uit:

// Lot-schema (vereenvoudigd)
const LotSchema = {
  lotNumber: number,
  title: string, // bijv. "Lot 42 - 85 stuks zwarte Angus stieren"
  headCount: number,
  averageWeight: number,
  breed: string,
  sex: 'steer' | 'heifer' | 'cow' | 'bull' | 'pair',
  location: { state: string, county: string },
  seller: Reference<Seller>,
  photos: Image[],
  videos: Video[],
  documents: File[], // gezondheidsgetuigschriften, merkinspecties
  epd: EPDData | null, // voor zaadstock
  deliveryTerms: string,
  startingBid: number | null,
  reservePrice: number | null, // verborgen voor bieders
};

Vloer-naar-online synchronisatie (Het moeilijke deel)

Dit is het stuk dat een echte simulcast platform onderscheidt van "gewoon video streamen met een biedingsknop". Je hebt een bediendinterface nodig — een toegewijde app die in de veilingring zit en de fysieke en digitale werelden verbindt.

De bediende (soms "online agent" genoemd) doet verschillende dingen:

  1. Partijen vooruitbrengen — Wanneer de veilingmeester naar de volgende partij gaat, tikt de bediende om het online systeem vooruit te brengen
  2. Vloerbiedingen doorgeven — Voer biedingen in die op de fysieke vloer zijn geplaatst in het systeem
  3. Online biedingen aankondigen — Roep online biedingen aan de veilingmeester aan ("Ik heb $152 op het internet!")
  4. Verkoopstatus controleren — Openingsbod, faire waarschuwing, verkocht, niet-verkocht, voorbij

Deze interface moet dood simpel zijn. De bediende werkt snel onder druk. Eentaps acties. Grote knoppen. Duidelijke visuele feedback. Geen bevestigingsdialogen tijdens actieve biedingen.

// Bediende interface toestandsmachine
type LotState = 
  | 'pending'      // Nog niet gestart
  | 'opening'      // Veilingmeester stelt het lot voor
  | 'bidding'      // Actieve biedingen
  | 'fair_warning' // "Faire waarschuwing, verkochte keer..."
  | 'sold'         // Hamer omlaag
  | 'no_sale'      // Niet aan reserve voldaan of geen biedingen
  | 'passed';      // Eigenaar haalde het lot terug

Auctionmarts.com handelt dit goed af — ze bieden directe communicatie tussen de online bieder en de veilingmeester, wat de gouden standaard voor simulcast is. De online bieder zou zich in de kamer moeten voelen.

Authenticatie, verificatie en fraudepreventie

Je kunt anonieme gebruikers geen $200.000 waard vee laten bieden. De verificatiepijplijn voor veestapelveilingen is strenger dan typische e-commerce:

  1. Registratie — Basisaccountaanmaak met volledige juridische naam, adres, telefoon
  2. Identiteitsverificatie — Overheids-ID-upload, geverifieerd door personeel (LMA Auctions vereist aparte biedregistratie met handmatige goedkeuring)
  3. Betalingsvooraf-autorisatie — Creditcardreserve of inkomstenbewijs (bankbrief)
  4. Kopernummeraantal — Unieke per-veilingskopenummer, net als ze op een fysieke veiling zouden krijgen

Stripe's Identity product behandelt het ID-verificatiedeel goed. Voor betalingsvooraf-auth is een $1 Stripe-reserve die je direct ongedaan maakt standaardpraktijk.

Fraudpatronen om naar uit te kijken:

  • Shill biedding — Dezelfde IP/apparaat biedt tegen elkaar
  • Bieding terugtrekkingsmisbruik — Bieden en dan terugtrekken voordat de hamer valt
  • Niet-betalende bieders — Gewonnen partij, betaalt nooit (dit is een enorm probleem in veestapel)
  • Geografische onmogelijkheid — Koper beweerd in Texas te zijn maar IP is in Roemenië

Je tech stack kiezen

Hier is wat ik in 2026 zou bouwen:

Laag Technologie Waarom
Frontend Next.js 15 (App Router) SSR voor catalogus SEO, React Server Components voor prestaties, geweldige DX
Bieding UI React + WebSocket (Socket.io of native WS) Real-time updates, optimistische UI
API Node.js (Hono of Fastify) Lage latentie, hoge gelijktijdigheid, TypeScript end-to-end
Database PostgreSQL (via Drizzle ORM) ACID-compliance is kritiek voor financiële transacties
Real-time Redis (Pub/Sub + state cache) Biedingsopdrachten, partijstatus, sessiebeheer
Berichtenwachtrij Kafka (op schaal) of BullMQ (MVP) Bieding verwerkingspijplijn, audittrail
Video Mux of Amazon IVS WebRTC + LL-HLS, adaptieve bitsnelheid
Betalingen Stripe Vooraf-auth, reserves, uitbetalingen aan verkopers
CMS Payload CMS of Sanity Lotcatalogi, mediabeheer
Hosting Vercel (frontend) + AWS/Fly.io (backend) Edge delivery voor wereldwijd bereik
Mobiel React Native of PWA Ranchers moeten kunnen bieden vanuit hun telefoons. Punt.

We doen veel Next.js-ontwikkelingwerk en het is hier passend. De cataloguspagina's profiteren enorm van server-side rendering — kopers zoeken op Google naar specifieke rassen, verkoopdatums en ranchnamen. Je wilt deze pagina's geïndexeerd hebben.

Voor lichtere catalogus-alleen sites of marketingpagina's rond de veiling, is Astro uitstekend. Snelle statische pagina's met eilanden van interactiviteit waar je ze nodig hebt.

DVAuction alternatieven: Concurrentielandschap in 2026

Als je aan het evalueren bent voor bouwen versus kopen, hier is het eerlijke landschap:

Aanpak Vooraf kosten Maandelijks kosten Controle Lanceringstijd
DVAuction / CattleUSA $0 Commissie per stuks (varieert, bel) Laag Dagen
White-label (LMA Auctions) Lidmaatschapskosten Commissie + tarief (bel 800-821-2048) Gemiddeld Weken
Aangepaste build (MVP) $80K-$200K $5K-$15K hosting/ops Vol 4-6 maanden
Aangepaste build (Volledig) $200K-$500K $10K-$30K hosting/ops Vol 8-14 maanden

De sweet spot voor de meeste veilinghuizen: bouw een aangepaste MVP, lanceer met 2-3 partnerabdijen, herhaal op basis van reëel gebruik. Je hoeft niet alle functies op dag één. Je hebt video, biedingen en een bediendinterface nodig die werkt.

Als je een aangepaste build aan het verkennen bent, neem contact op met ons team — we hebben exact deze afwegingen met clients in de landbouwsector doorgewerkt. Onze prijzpagina geeft je een startpunt voor scoping.

Ontwikkelingscyclus en realistische kosten

Hier is een realistische routekaart op basis van een team van 2-3 senior developers:

Fase 1: MVP (Maanden 1-4)

  • Gebruikersregistratie en kopersverificatie
  • Basislotcatalogus met foto's/beschrijvingen
  • Single-auction live videostream (WebRTC via Mux)
  • Online biedingen via WebSocket
  • Bediendinterface voor vloerbiedingsinvoer en lotvooruitgang
  • Stripe vooraf-autorisatie
  • Kosten: $80K-$150K

Fase 2: Schaal (Maanden 5-8)

  • Multi-auction ondersteuning (gelijktijdige verkopen)
  • Proxybiedingen
  • Volledige catalogus CMS met video, documenten, EPD-gegevens
  • Mobiele app (React Native) of gepolijste PWA
  • Koper-/verkoopersdashboards met geschiedenis
  • Na-verkoop afrekening en facturering
  • Kosten: $60K-$120K aanvullend

Fase 3: Groei (Maanden 9-14)

  • Multi-tenant white-label (verkoop aan andere veilinghuizen)
  • Analyticsdashboard (prijstrends, kopersgedrag)
  • On-demand replay van voorbije verkopen
  • TV/streaming apparaat-apps (Roku, Apple TV)
  • API voor integraties van derden (ranchbeheersoftware)
  • Kosten: $80K-$150K aanvullend

Ongaande hosting en operaties voor een gemiddeld-schaalplatform (5-10 verkopen per maand, 200-500 gelijktijdige bieders per verkoop) loopt $8K-$15K/maand. Videolevering is de grootste regelitem — budget $3-5K/maand gewoon voor streamingkosten op deze schaal.

Veelgestelde vragen

Wat is simulcast biedingen in veestapelveilingen? Simulcast biedingen betekent een enkele veiling uitvoeren waar biedingen tegelijkertijd van de fysieke verkoopschurvloer en van onlinebieders die een livestreamvideo bekijken, worden geaccepteerd. De veilingmeester betrekt biedingen van beide kanalen in real-time. Het verschilt van een zuiver online veiling — de fysieke verkoop vindt toch plaats, en online bieders nemen deel naast de mensen in de kamer.

Hoeveel kost het om een DVAuction alternatief te bouwen? Een functionele MVP met live videostreaming en real-time biedingen kost doorgaans tussen $80.000 en $200.000 voor initiële ontwikkeling, met $5.000-$15.000 per maand aan hosting en operationele kosten. Een volledig functioneel platform met mobiele apps, multi-tenant ondersteuning en geavanceerde analyses kan $200.000-$500.000+ kosten. De grootste variabele is videostreaminginfrastructuur — het is de duurste component zowel om te bouwen als om te bedrijven.

Welke videostreamtechnologie werkt het beste voor veestapelveilingen? WebRTC levert de laagste latentie (onder 1 seconde) wat kritiek is voor actieve bieders die de veilingmeester in real-time moeten zien. Voor toeschouwers die alleen kijken, biedt Low-Latency HLS (LL-HLS) 2-4 seconden vertraging tegen veel lagere afleveringskosten. De meeste succesvolle platforms gebruiken een hybride aanpak: WebRTC voor geverifieerde bieders en LL-HLS voor iedereen anders. Services zoals Mux, Amazon IVS en Ant Media Server ondersteunen allemaal dit patroon.

Hoe ga je om met bieding latentie wanneer online bieders concurreren met vloerbieders? Dit is de centrale technische uitdaging. Vloerbieders hebben nul latentie — de veilingmeester ziet hun hand onmiddellijk. Online bieders hebben netwerkvertraging. De oplossing is een bediende/agent die als brug fungeert. Online biedingen komen via WebSocket aan (doorgaans onder 100ms voor goed gebouwde systemen), en de bediende kondigt ze onmiddellijk aan bij de veilingmeester. Goede platforms geven de veilingmeester ook een visuele indicator van hangende online biedingen zodat ze een partij niet voortijdig sluiten.

Wat is de beste tech stack voor het bouwen van een real-time veiling platform? Next.js voor de frontend geeft je SEO-vriendelijke cataloguspagina's plus React's componentmodel voor de real-time bieding UI. Op de backend behandelt Node.js met WebSocket-ondersteuning de real-time biedingen goed op schaal. PostgreSQL voor transactionele gegevens (biedingen, partijen, betalingen) en Redis voor real-time statusbeheer. Voor video, een beheerde service zoals Mux of Amazon IVS bespaart je enorme complexiteit. Deze stack behandelt alles van kleine zaadstock verkopen tot 15.000+ stuks evenementen.

Heb ik een mobiele app nodig voor een veestapelveiling platform? Ja. Volledige stop. Een significant percentage van je bieders zal op mobiele apparaten zijn, vaak op plaatsen met beperkte connectiviteit. Een Progressive Web App (PWA) is het snelste pad naar mobiele ondersteuning en werkt goed als je voor lage bandbreedte optimaliseert. Een native React Native app geeft je betere achtergrondaudio-ondersteuning (kritiek — bieders luisteren naar de veilingmeester terwijl ze lotinformatie controleren) en push-notificaties voor lotwaarschuwingen.

Hoe verdienen veestapelveiling platforms geld? De meeste platforms rekenen verkopers een commissie per stuks verkocht of een percentage van het totale verkoopsmaximum. Koperspremies zijn minder gebruikelijk in veestapel dan in andere veilingsingreddiënten. Sommige platforms rekenen veilinghuizen een vast maandelijks abonnement plus een per-veilingskosten. Anderen bieden het platform gratis aan veilinghuizen en nemen een percentage van bruto handelswaarde. Het commissiegebaseerde model is het meest voorkomend, met koersen doorgaans variërend van 1-5% afhankelijk van volume.

Welke regelgeving is van toepassing op online veestapelveilingen? Online veestapelveilingen moeten voldoen aan staatsspecifieke regelgeving voor veestapelmarketing, die aanzienlijk varieert. De meeste staten vereisen dat veilingoperators een runderhandelaar of marktinstellingslicensie hebben. De USDA's Packers and Stockyards Act bepaalt eerlijke handelspraktijken. Je moet ook merkinspecties, gezondheidsgetuigschriften en documentatie voor interstataal vervoer verwerken. Werk met een landbouwavocat in je doelstaten voordat je start — dit is niet optioneel.