Gifting is een markt van 33 miljard dollar. De software die je kunt kopen, is er meestal niet voor gebouwd.

Denk aan het laatste cadeau dat je online verstuurde. Jij betaalde ervoor, maar het kwam niet naar jou. Het ging naar iemand anders, idealiter op een bepaalde dag, idealiter met een boodschap die niet las als een verzendmelding, en het geheel werkte alleen als die ander verrast werd. Kijk nu naar zowat elke e-commerce stack: één account, één winkelwagen, één verzendadres, één bevestigingsmail. Gifting is de handelsflow die stilletjes elke aanname tegenspreekt waarop de onderliggende software is gebouwd.

Die mismatch is de reden waarom zoveel gifting-bedrijven uiteindelijk blijven zitten met een lappendeken van plugins, handmatige workarounds, en een klantenservicewachtrij vol 'mijn cadeau ging naar het verkeerde adres'-tickets. Het is ook waarom gifting telkens terugkomt als een bouwen-of-kopen-vraag die lastiger is dan ze lijkt. De markt is groot genoeg om de moeite waard te zijn om goed te doen, en specifiek genoeg dat de voor de hand liggende tools meestal niet passen. Dus loont het om helder te zijn over waarom, en over wat er echt van jou is om te bouwen.

De cijfers zijn groter dan de seizoensreputatie doet vermoeden

Gifting heeft een imagoprobleem binnen productteams: het klinkt als iets voor december. De data zeggen iets anders. De markt voor gepersonaliseerde cadeaus zit in 2026 ergens rond de 33 tot 35 miljard dollar, en die klimt al een tijd nu maatwerk verschuift van een nieuwigheid naar een standaardverwachting. Meer dan de helft van de shoppers zegt nu een meerprijs te betalen voor iets dat aanvoelt alsof het voor de ontvanger gemaakt is, wat een nette manier is om te zeggen dat de race naar de bodem voor generieke producten hier niet opgaat.

De digitale kant beweegt nog sneller. E-gifting (direct geleverde bonnen, in een wallet inwisselbaar tegoed, stuur-het-nu-open-het-later-flows) is het snelst groeiende segment van de bredere cadeaubonmarkt, dat met ruwweg 20% per jaar groeit terwijl de categorie als geheel in de midden-tien procent draait. De reden is alledaags en krachtig: een digitaal cadeau kan om 23.00 uur gekocht worden, ingepland voor een verjaardag drie weken later, en ingewisseld vanaf een telefoon zonder enige verzending. Elk van die gemakken is een functie die je software ofwel native ondersteunt ofwel slecht namaakt.

Dus de vraag is duurzaam, ze beloont personalisatie, en ze helt over naar digitaal. Niets daarvan vertelt je echter of je software moet bouwen. Het vertelt je alleen dat de prijs het argument waard is.

Waarom generieke e-commerce software blijft struikelen over gifting

Het kernprobleem is de splitsing tussen koper en ontvanger, en die werkt door naar een verrassend aantal plekken. Begin bij het adres. Wie betaalt, weet vaak niet waarheen te verzenden. Diegene kent een e-mail of een telefoonnummer, geen straat. Een echte gifting-flow vereist dat de ontvanger achteraf zijn eigen leveringsgegevens invult, wat betekent dat de bestelling in een half-afgeronde staat moet bestaan en zichzelf dagen later afrondt. Een standaard checkout kent dat concept niet.

Dan is er de timing. Cadeaus zijn gekoppeld aan datums (een verjaardag, een jubileum, een feestdag), dus 'lever op deze dag, niet eerder, niet later' is geen nice-to-have, het is de hele bedoeling. Dat botst met fulfilmentsystemen die zijn geoptimaliseerd om zo snel mogelijk te verzenden. Je hebt een planningslaag nodig die een bestelling vasthoudt, een kalender in de gaten houdt, en ze op het juiste moment vrijgeeft, inclusief de afhandeling van het geval waarin de ontvanger het cadeau nooit opeist.

Voeg daar het zachte spul aan toe dat dragend blijkt te zijn: een cadeauboodschap die als een kaartje verschijnt, niet als een regelitem; cadeauverpakking of een digitaal onthulscherm; de mogelijkheid om de prijs te verbergen; groepscadeaus waar vijf collega's bijdragen en één van hen afrekent. Elk hiervan is op zichzelf een kleine functie. Samen beschrijven ze een productcategorie die kant-en-klare winkelwagens als randgevallen behandelen, en randgevallen zijn precies waar aangeplakte apps met elkaar vechten om de controle over de checkout.

Grensoverschrijdend maakt het erger. Gifting is een van de weinige categorieën waar verzender en ontvanger geregeld in verschillende landen zitten, wat betekent dat valuta, belasting en douane allemaal moeten buigen rond een transactie die het platform als één eenvoudige verkoop ziet. Tegen de tijd dat je dit allemaal op een generieke winkel hebt gelapt, heb je in feite een gifting-systeem gebouwd, alleen een dat met ducttape aan elkaar hangt, met de naden zichtbaar in je supportinbox.

Maar daar zijn toch platforms voor? Lossen die het niet op?

Enigszins, voor een specifieke koper. De bekende namen (Sendoso, Reachdesk, Snappy en hun soortgenoten) zijn echt goed in zakelijke gifting. Ze koppelen aan een CRM, laten een salesvertegenwoordiger een merkdoos of een e-cadeau sturen op het moment dat een deal stokt, en rapporteren terug hoe gifting de pipeline beïnvloedde. Als je doel is om gifting een onderdeel van je omzetbeweging te maken, is een van deze kopen de juiste keuze en zou je eigen bouwen onzinnig zijn.

Dat is een ander soort bedrijf dan een gifting-merk zijn. Deze platforms zijn afgesteld op B2B-zendingen met laag volume en hoge waarde, gemeten in beïnvloede omzet. Ze draaien op jaarabonnementen met minimale verplichtingen en publiceren zelden prijzen, omdat het model uitgaat van een salesteam, niet van een consumentenrun op Moederdag. Je koopt ook hun catalogus, hun fulfilmentpartners, en hun idee van hoe het uitpakken moet aanvoelen. Voor een marketingteam is dat prima. Voor een merk waarvan de hele waarde het cadeau zelf is, is de ervaring aan een derde partij overhandigen het product weggeven.

Dus de eerlijke framing is niet 'bouwen vs. kopen' als één vraag. Het zijn twee vragen. Is gifting iets wat je doet om een ander bedrijf te ondersteunen, of is gifting het bedrijf? Is het het eerste, koop dan. Is het het laatste, dan brengen de platforms je tot een demo en stoppen ze precies waar jouw onderscheidend vermogen begint.

Wat het in 2026 echt waard is om te bouwen

Heb je besloten dat gifting het bedrijf is, dan is de truc om de delen te bouwen die van jou zijn en de rest te huren. Een paar gebieden lonen op dit moment, en een paar zijn makkelijk om te veel geld aan uit te geven.

De beslislaag, geholpen door AI

Het moeilijkste moment in gifting is niet de checkout, het is 'ik heb geen idee wat ik voor ze moet kopen'. Daar verdient AI zijn brood. Een aanbeveler die een budget, een gelegenheid en een handvol feiten over de ontvanger meeneemt en drie goede opties teruggeeft, neemt precies de frictie weg die cadeauwinkelwagens om zeep helpt. Dit is het waard om goed te bouwen. Wat het niet waard is om te bouwen, is een generieke chatbot die aan de homepage is geniet. De waarde zit in de cadeaubeslissing, niet in het gesprek.

Planning en de overdracht aan de ontvanger

De flow van plannen-op-een-datum en de ontvanger-vult-het-adres-in is het meest waardevolle om volledig in eigen hand te hebben, omdat het het ding is dat generieke tools niet kunnen namaken en klanten meteen opmerken wanneer het soepel loopt. Bouw de order-state-machine die half-afgerond kan blijven staan, stuur de ontvanger een nette claim-link, herinner diegene als die niet reageert, en geef op de juiste dag vrij aan fulfilment. Krijg je dit goed voor elkaar, dan verdwijnen de meeste van je gifting-specifieke supporttickets.

Digitale levering en de onthulling

Omdat e-gifting het snelst groeiende stuk is, wordt een direct digitaal pad (een bon of tegoed geleverd via link of wallet, te openen op de dag zelf) steeds vaker de standaard in plaats van een extraatje. Het onthulscherm dat de ontvanger ziet, is onderdeel van je product, dus het hoort bij jou, niet bij een e-mailsjabloon dat je niet beheert. Groepscadeaus passen hier ook: meerdere mensen aan één cadeau laten bijdragen is mechanisch een tikje priegelig (gesplitste betalingen, een pot, een deadline) en wordt onevenredig geliefd door gebruikers als het werkt.

Wat te huren, niet te bouwen

Betalingen, fraude, transactionele e-mail, opslag, en de onderliggende catalogus- en checkout-plumbing zijn allemaal opgeloste problemen met goede aanbieders. Bouw ze niet opnieuw om een punt te maken. Hetzelfde geldt voor de meer modieuze extra's. AR-previews van 'pas het cadeau in je kamer' en dergelijke kunnen echt zijn, maar ze zijn een fase-twee-experiment, geen reden om de lancering uit te stellen. Duurzaamheids- en herkomstdetails (waar een cadeau vandaan kwam, zijn voetafdruk) worden stilletjes een onderscheidend kenmerk bij jongere kopers, en ze zijn goedkoop om later toe te voegen als data, niet als een herbouw.

Hoe je begint zonder een kathedraal te bouwen

De faalmodus hier is beslissen dat gifting speciaal is en daarom alles vanaf nul herbouwen. Dat hoeft niet. Houd een bestaande commerce-ruggengraat voor catalogus, betalingen en fulfilment, en steek je engineering in de gifting-laag die daar bovenop zit: planning, de overdracht aan de ontvanger, boodschappen, en één personalisatiefunctie die je kunt aanwijzen als de reden waarom mensen voor jou kiezen. Dat is een eerste versie in de range van een normale MVP, geen platform van meerdere jaren.

De doorslaggevende vraag is dezelfde waarmee we begonnen. Ben je een marketing- of salesteam dat cadeaus wil sturen, koop dan een zakelijk platform en ga door. Is het cadeau het ding dat je verkoopt, dan brengen de kant-en-klare opties je tot aan de rand van je idee en niet verder, en het deel dat ze niet kunnen is precies het deel dat de moeite waard is om te bezitten. Bouw dat, huur de rest, en weersta de drang om de kathedraal te bouwen voordat je bewezen hebt dat iemand de kapel wil.