Een embeddable widget is code die je klanten in hun eigen websites plakken: een analyticssnippet, een chatbubbel, een boekingsformulier, een meetverzamelaar. Het is de moeilijkste soort front-endengineering, juist omdat alles wat een gewoon webproject vanzelfsprekend vindt wegvalt — je kiest het framework niet, de browserondergrens niet, de andere scripts op de pagina niet, en ook niet wanneer je gebruikers upgraden. Je code is te gast in andermans huis, en hij moet zich in elk huis tegelijk onberispelijk gedragen.

Dit is een nichediscipline, en we hebben er een echte referentie in: een signaalverzamelaar die wij bouwden draait ingebed in duizenden sites die we niet beheren, en voedt een platform dat tienduizenden verzoeken per minuut beoordeelt.

De producten die we bouwen

  • Meet- en analyticsverzamelaars — scripts die signalen van een pagina verzamelen en naar je platform sturen, zoals dat achter ons botdetectiewerk
  • Functionele widgets — chat, boekingen, formulieren, rekentools: een stuk van jouw product dat in de pagina van je klant leeft
  • Integraties via een snippet — de onboarding van "voeg één scripttag toe" die jouw product voor de bezoekers van je klant zet
  • De ingest achter het script — de backend die ontvangt wat de snippet verstuurt, op welk volume het verkeer van je klanten ook uitkomt
  • Het dashboard waarmee je klanten meekijken — rapportage- en configuratieoppervlakken behandelen we op beheerpanelen en dashboards

Wie je embeddable script bouwt

We bouwden er één van begin tot eind, van de snippet tot het platform erachter.

Een verzamelaar in duizenden vijandige pagina's

Voor een realtime platform voor botdetectie bouwden we de verzamelaar in de browser die het bewijs vergaart waarop een oordeel mens-of-bot wordt gebaseerd. Het is kale JavaScript — geen framework, geen runtime uit een build, geen afhankelijkheden — omdat hij in duizenden pagina's draait naast wat die pagina's verder ook laden, geen modulesysteem of polyfillset mag aannemen, en nooit mag botsen met de site eromheen. Hij werkt in een actief vijandige omgeving: wat hij meet, probeert hem te verslaan. En hij is klein, omdat elke kilobyte wordt afgeschreven op het prestatiebudget van de klant zelf, bij elke paginaweergave, voor altijd.

En het platform dat ontvangt wat hij verstuurt

Een snippet is het zichtbare tiende deel van het systeem. Achter die verzamelaar bouwden we de ingest- en scoringsservices in Go en het dataplatform eronder — want een embed die slaagt vermenigvuldigt zijn eigen verkeer met elke klant die hem installeert, en de backend moet vanaf dag één op die rekensom zijn ontworpen. De volledige architectuur staat in de casestudy.

Wat ingebedde code werkelijk vraagt

Vijf beperkingen onderscheiden dit werk van gewone front-endengineering.

Een omvangbudget in kilobytes

Je script gaat naar elke bezoeker van elke klant. Een frameworkruntime zou groter zijn dan een complete, goed gebouwde verzamelaar — en daarom zijn serieuze embeds zonder afhankelijkheden gebouwd uit noodzaak, niet uit voorkeur. Klein blijven is een functie die terug te zien is in de Lighthouse-scores van je klanten.

Geen enkele aanname over de hostpagina

Geen modulesysteem, geen ondergrens van moderne browsers, geen garantie dat de pagina niet al een botsende bibliotheek laadt, een al te gretige CSS-reset, of een tweede kopie van je eigen script. Alles draait in een eigen scope, raakt de globale namespace hooguit één keer aan, en degradeert stil in plaats van andermans afrekenproces te breken.

Defensief door ontwerp

De pagina waarin je code draait kan eromheen geïnstrumenteerd, aangepast of geëmuleerd zijn — in ons botdetectiewerk is de meting verslaan precies de taak van de tegenstander. Ook bij vriendelijkere embeds houdt de les stand: lees browser-API's rechtstreeks uit, verifieer in plaats van de omgeving te vertrouwen, en houd elk oordeel aan de serverkant, waar de logica niet zichtbaar is voor de pagina.

Versionering die je niet kunt afdwingen

Klanten plakken je snippet één keer en raken hem daarna nooit meer aan. Die ene regel moet een stabiele loader blijven terwijl alles erachter evolueert — gefaseerde uitrol, een onbreekbaar contract tussen loader en payload, en compatibiliteit die jaren wordt onderhouden, want "werk alsjeblieft je embedcode bij" is een e-mail die niemand beantwoordt.

Toestemming en privacy als architectuur

Een script van een derde partij is een derde partij — de geldt op elke site die het installeert. Wat het script verzamelt, wanneer het mag draaien ten opzichte van de toestemmingsstatus van de hostpagina, en wat er over de lijn gaat, zijn ontwerpbesluiten die we vooraf expliciet maken — zodat jouw embed iets is dat de compliancecontroles van je klanten kunnen goedkeuren in plaats van aankaarten.

Hoe we werken

Bouw met vaste scope. Snippet, loader, ingest en de uitrolpijplijn die ze veilig versioneert — als één systeem gescopet en opgeleverd.

Teamuitbreiding. Onze engineers sluiten aan bij het team dat je platform bezit — zie teamuitbreiding.

Hoe dan ook sturen we, zodra we de eisen scherp hebben, binnen twee werkdagen een offerte met duidelijke scope.

Wat een embeddable widget kost

De snippet is klein; het systeem niet — een embed wordt geprijsd vanuit dezelfde gepubliceerde niveaus als de pagina webontwikkeling. De verzamelaar of widget met zijn loader en een slanke ingest valt in het webappniveau op € 12.000-32.000; draagt het platform erachter echte schaal — scoring, analyse, klantdashboards — dan wordt het systeem als werk op SaaS-niveau geprijsd vanaf vanaf € 40.000.

Dit zijn dezelfde sleutels die de prijstabel van de pijler renderen, dus de twee kunnen niet uiteenlopen. Wat het bedrag beweegt: hoe vijandig de omgevingen zijn die je script moet overleven, hoeveel verkeer de pagina's van je klanten bij elkaar optellen, en hoeveel van het ontvangende platform al bestaat.

Veelgestelde vragen

Veelgestelde vragen van teams die code uitleveren aan andermans pagina's.

Omdat de frameworkruntime groter zou zijn dan de hele widget, en omdat de hostpagina misschien al een andere versie van hetzelfde framework draait, of een globale omgeving heeft die met de jouwe vecht. Een embed die naar elke bezoeker van elke klant gaat, wordt afgemeten aan het prestatiebudget van elke klant zelf, dus serieuze ingebedde scripts zijn bewust kale JavaScript zonder afhankelijkheden. De eigen site van je product mag zo frameworkzwaar zijn als hij wil — de code die op reis gaat moet zelfvoorzienend zijn.
Door niets aan te nemen en niets aan te raken. Alles draait binnen een eigen scope, de globale namespace wordt hooguit één keer aangeraakt, stijlen zijn geïsoleerd zodat de CSS van de hostpagina er niet in of uit kan lekken, en elk faalpad degradeert stil — een kapotte widget mag nooit het afrekenproces van een klant meesleuren. We bouwen vanaf het begin tegen vijandige paginacondities, omdat de verzamelaar die we draaien meedraait naast wat duizenden ongerelateerde sites ook maar laden.
De geplakte regel is nooit het product — het is een kleine, stabiele loader die de actuele payload ophaalt. Het contract tussen loader en payload is de ene interface die nooit mag breken, en alles erachter kan dan evolueren: gefaseerde uitrol eerst naar een fractie van het verkeer, geversioneerde payloads, en direct terugrollen wanneer een browserrelease je verrast. Die naad op dag één goed ontwerpen is wat van 'werk alsjeblieft je embedcode bij' een e-mail maakt die je nooit hoeft te sturen.
Een script van een derde partij is onder de AVG een derde partij op elke site die het installeert, dus ontwerpen we vanaf het begin voor toestemming. We maken expliciet wat het script verzamelt, of iets daarvan een persoon identificeert, en hoe het zich gedraagt ten opzichte van de toestemmingsstatus van de hostpagina — inclusief draaien in een modus zonder toestemming waar compliance dat vereist. Het doel is een embed die de privacybeoordelingen van je klanten zonder vergadering kunnen goedkeuren.
Ja, en we bouwen liever beide kanten dan een van de twee. Een succesvolle embed vermenigvuldigt zijn verkeer met elke klant die hem installeert, dus de ingest moet vanaf het begin op het opgetelde volume zijn ontworpen — het platform achter onze verzamelaar beoordeelt tienduizenden verzoeken per minuut in realtime, op Go-services die we van begin tot eind bouwden. De snippet en zijn backend zijn één systeem, en de faalwijzen leven op hun naad.
Een widget of verzamelaar met zijn loader en een slanke ingest kost doorgaans 15.000 tot 40.000 dollar over één tot drie maanden — het gepubliceerde webappniveau op onze pagina over webontwikkeling. Is het ontvangende platform het echte product — realtime scoring, analyse, dashboards voor klanten — dan wordt het systeem als werk op SaaS-niveau geprijsd, meer dan 50.000. De snippet zelf is zelden het dure deel; het volume dat hij genereert wel.

Lees hoe de verzamelaar in het hele systeem past in de casestudy over botdetectie, bekijk de Go-services erachter, of begin bij de pijler webontwikkeling.