White-label Umbraco-development: hoe bureaus De Codebrouwerij inzetten
Een vast Umbraco-team achter de bureau-vlag. Geen zichtbaarheid richting de eindklant, één aanspreekpunt en werkafspraken die jouw klanten nooit hoeven te kennen.
Het korte antwoord
Bureaus die regelmatig Umbraco-werk binnenkrijgen staan vroeg of laat voor dezelfde keuze: zelf opbouwen, freelancer per project, of een vaste partner in de achtergrond. Voor veel bureaus is die derde optie het meest stabiel — een Umbraco-team dat onzichtbaar achter jouw merk werkt, jouw eindklant nooit ziet, en altijd inzetbaar is wanneer een pitch landt.
Dat is wat we bedoelen met white-label: wij bouwen, jij levert op. Voor de eindklant is er één projectteam, één aanspreekpunt, één factuur, en die staan allemaal op jouw briefpapier. Wij staan in de achtergrond, met onze handen aan de Umbraco-installatie en onze mond dicht over wie de bouw daadwerkelijk heeft uitgevoerd. Het bureau-model van De Codebrouwerij draait inmiddels al jaren op deze manier.
In dit artikel leg ik uit hoe die samenwerking concreet werkt, welke afspraken nodig zijn om het zonder ruis te laten lopen, en waar bureaus die de overstap overwegen typisch tegenaan lopen. Geen verkooppraatje — wel een eerlijke uitleg van het model.
Wat white-label echt betekent
White-label is een woord dat door veel partijen anders ingevuld wordt. Voor de duidelijkheid: bij ons betekent het drie dingen.
Eén — geen zichtbaarheid richting de eindklant. Onze naam staat niet in offertes, niet in oplevermails, niet op LinkedIn-posts en niet in de footer van de site. We bestaan voor jouw klant niet. Dat klinkt simpel, maar het vraagt discipline aan beide kanten. Geen Codebrouwerij-domein in commits, geen ondertekening met onze namen in mailwisseling die richting de klant gaat, geen taggen in social posts achteraf.
Twee — jij voert de communicatie, wij voeren de bouw. Strategie, scope, planning richting de klant, status-updates — dat blijft bij het bureau. Wij leveren wat technisch nodig is in een vorm die jij rechtstreeks kunt doorzetten: korte tussentijdse demo's, helder geschreven oplevernotities, screenshots van staging. Daar zit geen ruis tussen. De accountmanager hoeft niet te vertalen wat de developer bedoelde.
Drie — werkafspraken die voorspelbaar zijn. Vaste contactpersoon aan onze kant, vaste cadans (meestal twee keer per week kort), één gedeeld project-board waar tickets, demo-links en releases doorheen lopen. Geen ad-hoc Slack-vragen die in een chaos eindigen.
Wat white-label niet is: detachering. Bij detachering werkt onze developer voor een paar maanden onder jouw teamleider, in jouw stack, met jouw tooling. Dat doen we ook, het is een prima model voor bepaalde situaties (groot intern team, korte boost nodig), maar het is iets anders dan white-label. In een eerder artikel zetten we de twee modellen tegenover elkaar.
Hoe het in de praktijk werkt
Genoeg theorie. Zo loopt een typisch white-label-project bij ons, van eerste belletje tot oplevering.
De brief van het bureau. Het start zelden met een uitgewerkt requirements-document. Vaker krijgen we een pitch-deck, een design in Figma, of een lijst features in een mail. Dat is genoeg. We lezen, stellen tien tot vijftien vragen terug (meestal in één pagina), en geven binnen twee werkdagen een eerste indicatie van scope, doorlooptijd en kosten. Geen formeel offertetraject met handtekeningen en disclaimers — dat komt later — maar wel concreet genoeg om door te kunnen pakken.
De scope-sessie. Eén of twee video-calls van een uur waarin we de aannames testen. Welke documenttypes komen er? Hoe ziet de redactieflow eruit? Welke externe systemen hangen er aan? Hoeveel content komt er over uit een oude site? Aan het einde van die sessie ligt er een aanpak op tafel waar het bureau richting de eindklant mee verder kan.
De bouwfase. Wij draaien sprints van twee weken. Aan het eind van elke sprint krijg jij een staging-URL, een korte schermopname met wat er live staat, en een lijst van wat er klaar is voor jouw klant-demo. Geen technisch jargon — wel zinnen die je zonder vertaling door kunt sturen. Vragen tussendoor lopen via één kanaal (meestal een gedeelde Slack of Teams), niet via vier verschillende inboxen.
De oplevering. Op de afgesproken datum staat de site live, draait de hosting waar het hoort, zijn redacteuren ingewerkt en is er een beknopt overdracht-document. Dat document staat op jouw briefpapier. Wij doen de inhoud, jij de buitenkant. Daarna start de onderhoudsfase: vaste onderhoudsafspraken die ook weer onder jouw merk lopen.
Wat in de praktijk de meeste tijd bespaart, is het achterwege laten van een trapje aan tussenpersonen. De projectmanager bij het bureau praat rechtstreeks met onze lead-developer. Geen accountmanager die mailtjes doorstuurt, geen wekelijkse rapportage die niemand leest. Veel bureaus die bij ons binnenkomen hebben net een project achter de rug waarin precies dat misging.
White-label werkt alleen als beide kanten dezelfde kwaliteitsdrempel hanteren. Als wij iets met wat onze code te maken heeft niet goed vinden, zeggen we dat tegen het bureau, niet richting de eindklant. Andersom: feedback van de eindklant die via het bureau bij ons binnenkomt, behandelen we even serieus alsof we de klant zelf voor ons hadden. Geen dunne lagen tussen team en oordeel.
Samenwerkingsmodellen op een rij
Niet elke samenwerking ziet er hetzelfde uit. We werken in de praktijk in drie smaken:
Per-project. Bureau pitcht, wint, schakelt ons in voor de bouw. Vaste prijs of dagstaffel, duidelijke deliverable, duidelijke einddatum. Goed voor bureaus die incidenteel een Umbraco-project hebben en niet vol willen instappen op een doorlopend partnerschap. Doorlooptijd typisch zes weken tot vier maanden per project.
Strippenkaart / retainer. Een vast aantal uren per maand voor onderhoud, features en kleine verbeteringen. Bureaus met een portfolio van actieve Umbraco-sites die niet voor elk klein dingetje een offerte willen aanvragen. Voorspelbaar voor jou, voor ons en voor de klant.
Partner-arrangement. Voor bureaus die Umbraco als vaste pijler in hun aanbod hebben. Wij worden onderdeel van het propositie-team, denken mee in pitches, leveren tijdsindicaties op vragen die nog niet uitgewerkt zijn en zijn vast inzetbaar wanneer een trefzeker antwoord nodig is. Hier ligt het meeste vertrouwen, en daar zijn dan ook meerdere jaren samenwerking aan voorafgegaan.
Het is geen ladder die je verplicht moet beklimmen. Sommige bureaus blijven bewust op per-project — werkt prima. Andere groeien in twee jaar door naar het partner-niveau. Wat hetzelfde blijft is de manier van werken: directe communicatie, één aanspreekpunt, geen overhead.
Daaronder ligt nog steeds de keuze die elk bureau aan het begin maakt. Hier zijn de drie fases waar je doorheen gaat als je overweegt om white-label op te zetten:
-
Eerste call waarin we kijken of er een natuurlijke fit is. Wat voor klanten heeft het bureau, hoe ziet de pipeline eruit, welke Umbraco-vragen komen typisch terug? We zeggen even vaak "nee" als "ja" — sommige bureaus zoeken iets wat wij niet zijn, en dat is prima om vroeg te ontdekken. Geen verplichting aan de gespreksrand.
-
Een eerste concrete opdracht — vaak een component, een migratie of een kleinere build — om te zien hoe de samenwerking in de praktijk loopt. Hier blijkt of de communicatie soepel verloopt, of het tempo klopt en of de overdracht richting de eindklant werkt zoals afgesproken. De drempel is bewust laag.
-
Als de pilot goed loopt, groeit het natuurlijk door naar terugkerend werk. Daar leggen we niets formeel in vast — geen exclusiviteit, geen minimum-afname, geen jaarcontract. Het werkt zolang het werkt. Dat geeft beide kanten de ruimte om eerlijk te blijven over wat goed gaat en wat beter kan.
Valkuilen aan beide kanten
White-label klinkt soms gladder dan het in de praktijk is. Een paar dingen die we beide kanten geregeld zien:
De accountmanager wil tussen-vertalen. Soms ontstaat de reflex om elke developer-vraag via de account-laag te laten lopen. Dat trekt tempo eruit en introduceert ruis. Beter: laat de projectmanager direct met onze developer praten over inhoud, en houd de account-laag voor strategie en commerciële afstemming. Wel zo prettig voor iedereen.
De eindklant wil ineens een meeting met "jullie tech-team". Dat gaat vaker over vertrouwen dan over techniek. Een kort tripartiet gesprek waarin wij meedraaien onder de bureau-vlag is meestal genoeg om dat vertrouwen op te bouwen. We doen die meetings, maar altijd onder de afspraken die vooraf zijn vastgelegd — geen visitekaartjes, geen aparte mailadressen.
Scope-creep aan de bureau-kant. Bureaus die druk zijn vergeten soms dat scope-uitbreidingen ook bij ons doorlopen. Een klein "kunnen we ook even..." verschuift het einde van de sprint. Met een gedeeld board en heldere change-procedure los je dat op, maar het vraagt afspraken.
Onderhoudsfase onderbelicht laten. Veel offertes focussen op de bouw en stippelen "onderhoud" als losse zin aan het eind. In de praktijk vraagt onderhoud net zoveel doordenken als de build. Wij brengen daar voor de zekerheid altijd een paar varianten op tafel, zodat de eindklant niet een halfjaar later voor een onverwachte rekening staat.
Te lang doorgaan met een ongelijke fit. Sommige samenwerkingen werken niet, en dat is geen ramp. We zeggen het liever na drie projecten dan na drie jaar. Dat geldt ook andersom — als een bureau merkt dat wij niet het type partner zijn dat ze zoeken, hopen we dat ze het zeggen.
Wanneer dit past, wanneer niet
White-label-werk past goed bij bureaus die strategisch sterk zijn, design en frontend zelf kunnen draaien, en regelmatig Umbraco of .NET-projecten binnenkrijgen waar ze geen vast intern technisch team voor willen optuigen. Voor die situatie zijn wij de stille keuken erachter — voorspelbaar, vasthoudend en niet zichtbaar.
Het past minder goed bij bureaus die liever alles intern willen houden, of die zoekend zijn naar een freelance-platform-achtige flexibele schil. Daar zijn andere partijen die dat beter doen dan wij.
Wil je verkennen of dit voor jouw bureau past? Lees meer over hoe we met bureaus werken of stuur een kort bericht met de situatie van je eerstvolgende Umbraco-pitch. Eén gesprek van een uur is meestal genoeg om te zien of er een natuurlijke samenwerking ontstaat — en zo niet, dan heb je in elk geval een eerlijke second opinion gehad.