Black Friday is over vijf weken, en de feature freeze op je kalender heeft nog steeds geen vaste datum. Voordat de uitrol stopt, heb je een plan nodig voor wat er nu live gaat en wat tot januari wacht. Een feature freeze beschermt de omzet, maar het stopt ook bijna alles wat een ontwikkelingsteam normaal gesproken doet gedurende vier tot tien weken. Deze gids zet de data uiteen die retailers daadwerkelijk gebruiken, de checklist die je vooraf moet afwerken en hoe je een echt noodgeval aanpakt zodra de freeze van kracht is.
Wat een feature freeze daadwerkelijk blokkeert
Een feature freeze is een vastgesteld venster waarin een team stopt met het uitbrengen van nieuwe, voor klanten zichtbare wijzigingen aan een live product. Teams stellen doorgaans hun eigen deployment-freezes in, die een tot twee weken rond Black Friday duren en nog eens een tot twee weken rond Kerst en Oud en Nieuw. Shopify behandelt de twee freezes als afzonderlijke fasen. Op een normale dag verstuurt het bedrijf ongeveer 40 nieuwe versies van zichzelf, waarna dat tempo wordt verlaagd door een feature freeze gevolgd door een code freeze in de weken voor BFCM. Tijdens de feature freeze-fase gaat het werk door, maar blijven de meeste functies die zichtbaar zijn voor gebruikers onaangeroerd, zodat niets nieuws de klanten verrast. Zodra de code freeze begint, bereiken alleen kritieke fixes de productie.
Een freeze heeft een reële beperking die het waard is om te kennen voordat je erop vertrouwt. Het beschermt een site niet tegen de release die in september is uitgerold; het beschermt alleen de laatst geteste versie door verdere wijzigingen te stoppen. Alles wat al is uitgerold, inclusief een wijziging van de vorige maand die nooit piekverkeer heeft gezien, blijft staan tijdens de freeze. Een trage databasequery van oktober gaat rechtstreeks door naar december, tenzij iemand die eerst opmerkt.

Je freeze- en dooidata instellen
De vakantievoorbereidingsgids van Salesforce vertelt retailers om als veilige standaard een code freeze in te stellen tegen 1 november, en wijzigingen te beperken tot het begin van januari. Een planningstabel van 2026 die op die richtlijn is gebaseerd, zet vier duidelijke fasen uiteen. Een feature freeze op vrijdag 30 oktober stopt nieuw werk dat zichtbaar is voor klanten, een volledige freeze op vrijdag 13 november blokkeert code, configuratie, tags en sjablonen, de piekweek van 23 tot 30 november staat uitzonderingen alleen toe met goedkeuring van het management, en een geleidelijke dooi vanaf 1 december brengt de achterstand in kleine batches uit.
Sommige leveranciers publiceren hun planning in plaats van handelaren zelf te laten gissen. De freeze van 2025 van Searchspring begon op 3 november, pauzeerde het publiceren volledig vanaf 17 november, hield stand tijdens Black Friday op 28 november en Cyber Monday op 1 december, ontdooide kort voor kritieke updates, en bevroor vervolgens weer van 19 december totdat de normale bedrijfsvoering op 6 januari werd hervat. Niet elk bedrijf begint zo vroeg. OneSignal hanteerde een kortere productiefreeze van vrijdag 30 oktober tot woensdag 4 november, met ruimte om deze indien nodig te verlengen.

De checklist die je voor de freeze moet afwerken
E-commercebedrijven verdienen vaak 40 tot 60 procent van hun jaaromzet in alleen november en december, en daarom moet de site ruim voordat de freeze begint in goede vorm zijn. Teams ronden meestal eerst projecten met een grote impact af: sitesnelheid, site-inventaris, het afrekenproces, opties voor cadeauverpakkingen, waardepropositie-berichten en verlanglijst- of winkelwagenverlatersprogramma's.
Voorraadgegevens zijn het belangrijkst; ze moeten altijd de werkelijke voorraadniveaus en nauwkeurige levertijden tonen, aangezien niemand een cadeau wil dat na de feestdagen aankomt. Terugrekenen vanaf de freeze-datum is beter dan weken tellen. Stel eerst de freeze-datum vast, schrijf deze op en tel dan terug in testcycli in plaats van kalenderweken; de eerste week van november is het gebruikelijke doel. Fix tussen nu en begin november de drie pagina's met de hoogste omzet in plaats van te proberen ze allemaal aan te pakken.
Uitzonderingen afhandelen zonder de freeze te verbreken
Een wijziging krijgt alleen een uitzondering als deze iets repareert dat actief geld kost of klanten blokkeert, direct na de uitrol volledig in productie kan worden getest (smoke test), en een aangewezen belanghebbende heeft die bereid is het risico te dragen. Al het andere, oftewel nieuwe functies, refactors en niet-urgente fixes, wacht tot na de piek. De kostenlogica achter die regel is simpel. Een bug die op 15 december wordt uitgerold, wanneer consumenten last-minute cadeaus kopen, kan een retailer het drie- of viervoudige kosten van wat dezelfde storing in juli zou kosten.
Niet iedereen is het erover eens dat een algemene freeze voor elk team het juiste instrument is. Quantum Metric stelt dat volledige freezes in strijd zijn met Agile- en CI/CD-praktijken, kunstmatige deadlines creëren en de releases die daarop volgen compliceren. De voorgestelde middenweg staat risicovrije HTML- en CSS-wijzigingen toe, terwijl de freeze wordt gereserveerd voor missiekritieke systemen zoals betalingen, verzending en fraudedetectie. Tommy Tynjä, een senior engineering manager bij Spotify, gaat verder en noemt de volledige freeze een anti-patroon dat op zichzelf noch risico, noch instabiliteit vermindert.
Feature flags bieden een praktisch middenpad tussen deze standpunten. Hiermee kan een team de inzet van code ontkoppelen van de release van functies, waardoor code vroeg wordt verstuurd, maar de functionaliteit uitgeschakeld blijft totdat de freeze wordt opgeheven. Het gratis Developer-abonnement van LaunchDarkly biedt onbeperkte seats en productieklare flags voor meerdere omgevingen zonder kosten, wat de meeste zaken dekt die een klein team nodig heeft voor een gefaseerde uitrol als deze.
Wat als eerste uitrollen, wat kan wachten
Fix eerst de sitesnelheid en voorraadnauwkeurigheid, aangezien beide van invloed zijn op elke pagina die een shopper ziet tijdens piekverkeer. Leg de freeze-datum schriftelijk vast voordat je iets anders plant, en tel dan terug in testcycli in plaats van weken. Bewaar nieuwe functies, herontwerpen en niet-urgente refactors voor januari, en stuur alles wat niet kan wachten via een aangewezen belanghebbende en een productie-smoke test. Een korte freeze die iedereen daadwerkelijk respecteert, is beter dan een lange waar niemand zich aan houdt.





