De app van je klant had net zijn beste maand ooit. Het aantal aanmeldingen verdrievoudigde, de workflows die je hebt gebouwd draaien op volle toeren en de oprichter is in zijn nopjes. Dan valt de platformfactuur op de mat: twee miljoen workload units boven de planlimiet, gefactureerd tegen dertig cent per duizend. Dat is een overage van $600 bovenop een plan van $119 — en als je contract "hosting inbegrepen" zegt binnen een vast maandbedrag, dan komt die $600 uit jouw marge, niet uit het budget van de klant. Hun succes is zojuist jouw verlies geworden, en niets in je scope of work had dat voorzien.
Dit is het bepalende prijsrisico van het runnen van een no-code-bureau in 2026. Bubble factureert op verbruik, Webflow meet bandbreedte en contentvolume, en beide passen hun prijzen periodiek aan. Een vast tarief doet alsof die kosten voorspelbaar zijn. Dat zijn ze niet. De bureaus die dit overleven behandelen platformkosten als wat ze werkelijk zijn: een pass-through-kost die van de leverancier, via jouw boeken, naar de klant stroomt — waarbij je werkelijke inkomen de markup en de beheervergoeding is, nooit de vergoeding zelf.
Hoe Bubble je in 2026 daadwerkelijk factureert
Bubble's gepubliceerde prijzen lijken gematigd. Bij jaarlijkse facturering kosten webplannen $29 per maand voor Starter, $119 voor Growth en $349 voor Team, met een gratis tier op $0 en Enterprise op aanvraag. Maandelijkse facturering kost meer: respectievelijk $32, $134 en $399. Maar de planvergoeding is het kleinste deel van de meeste productiefacturen. De echte meter is de workload unit.
Elk betaald plan bevat een maandelijkse workload-unit-toelage: 175.000 units op Starter, 250.000 op Growth en 500.000 op Team. Het gratis plan bevat 50.000 maar kan geen live app deployen. Een workload unit meet serverwerk — databasezoekopdrachten, workflow-runs, API-calls, paginaladingen, bestandsbewerkingen — en het verbruik varieert enorm per bewerking. Een eenvoudige paginalading kost ruwweg een halve tot twee units; een enkele complexe zoekopdracht kan 10 tot 50 kosten. Een app met praatgrage workflows of niet-geoptimaliseerde zoekopdrachten kan een Starter-toelage opbranden lang voordat het verkeer indrukwekkend lijkt.
Wanneer de toelage op is, bedraagt het overage-tarief zonder enige add-on-tier $0,30 per 1.000 units. Een miljoen extra units in een maand — makkelijk voor een groeiende app met zware backend-workflows — kost $300. Vooraf gekochte workload-tiers verlagen het unit-tarief aanzienlijk, tot ongeveer $0,10 per 1.000 bij de grootste tier, maar je moet de tier kopen vóór de piek, en tiers zijn op zichzelf een maandelijkse verplichting.
Drie mechanismen maken dit specifiek voor bureaus verraderlijk. Ten eerste is verbruik oprecht moeilijk vooraf te voorspellen; twee apps met identieke aantallen gebruikers kunnen een orde van grootte verschillen in workload, afhankelijk van hoe hun workflows zijn gebouwd. Ten tweede staan overages standaard aan, en Bubble mailt de accounthouder bij 75 procent en 100 procent van de toelage — maar als jouw bureau het account beheert, gaat die e-mail naar jou, niet naar de klant wiens gebruikers de piek veroorzaakten. Ten derde betekent overages uitzetten niet dat de rekening netjes wordt afgekapt: de app gaat offline wanneer de limiet wordt bereikt, totdat overages weer worden aangezet, een tier wordt gekocht of de volgende cyclus begint. "De site lag eruit omdat we een gebruikslimiet raakten waar niemand op lette" is geen gesprek dat je met een klant wilt hebben.
Webflow heeft dezelfde vorm met andere meters
Webflow gebruikt geen workload units, maar de prijsstelling heeft vanuit het perspectief van een bureau hetzelfde volatiliteitsprofiel: een bescheiden basisvergoeding plus meters die meebewegen met het succes van de klant.
In mei 2026 voegde Webflow zijn oude CMS- en Business-siteplannen samen tot één Premium-plan: $25 per maand per site bij jaarlijkse facturering ($39 maandelijks), met 300 statische pagina's, 20.000 CMS-items en 50 GB bandbreedte. Het Basic-plan van $15 per maand omvat een aangepast domein en 10 GB bandbreedte, maar helemaal geen CMS. Alles boven de inbegrepen bandbreedte wordt verkocht als betaalde add-ons, tot 2,5 terabyte — dus een virale lancering van een klant of een zwaar kwartaal aan beeld- en videoverkeer vertaalt zich direct in een grotere Webflow-factuur.
En het siteplan is slechts één van drie rekeningen. Workspace-plannen voor design-samenwerking, extra designer-seats, extra locales en e-commerce-transactiecapaciteit worden allemaal apart gefactureerd, bovenop de vergoeding per site. Een klant die om "nog maar één extra taal" of "toegang voor twee extra editors" vraagt, vraagt je een metered stack te vergroten — en als je contract één vast maandbedrag noemt voor "website plus hosting", dan verkleint elk van die ja's je marge.
Beide platforms passen ook hun prijzen aan. Bubble paste de Starter-prijsstelling aan in oktober 2026; Webflow herstructureerde halverwege het jaar zijn hele siteplan-assortiment. Elke meerdaagse vaste offerte die de platformprijzen van vandaag bevat, is een weddenschap dat de leverancier stil blijft zitten. Die weddenschap verliest al jaren.
De contractfout: metered kosten bundelen in een vast tarief
De faalmodus is bijna altijd dezelfde zin, begraven in een voorstel of een master services agreement: een vast maandbedrag dat "hosting inbegrepen" heeft. Het leest als eenvoud voor de klant. In de praktijk maak je jouw bureau de verzekeraar van leveranciersvolatiliteit — je int een vaste premie en absorbeert onbeperkt metered neerwaarts risico.
Brancherapportage over bureauprojecten plaatst typische Bubble-projectkosten tussen $20.000 en $250.000, en wijst op de specifieke margeval: wanneer je een klantapp oplevert en het bedrijf van de klant succesvol wordt, stijgt het verbruik, en ofwel betaalt de klant meer waarvoor hij nooit had gebudgetteerd, ofwel absorbeert het bureau de stijging. Vaste prijs op vage scope is sowieso al de meest voorkomende bron van geschillen tussen bureau en klant in softwarediensten in het algemeen; een metered factuur van een derde partij binnen de vaste prijs toevoegen, maakt elke gebruiks piek tot een heronderhandeling.
Dezelfde val duikt een niveau dieper op in AI- en automatiseringswerk, waar bureaus die API- en tokenkosten in vaste retainers bundelen, ontdekken dat een prijswijziging van de leverancier van de ene op de andere dag hun verlies wordt. Platformkosten gedragen zich precies zoals tokenkosten: door derden gemeterd, door de klant gedreven en buiten je controle. Kosten met die drie eigenschappen horen niet in een vast tarief. Ze horen in een pass-through-clausule.
Er is een tweede, stiller nadeel aan bundelen: het verbergt de cijfers voor de klant. Een klant die de workload-unit-trend nooit ziet, heeft geen reden om het optimalisatiewerk goed te keuren dat die trend zou verlagen — een verspillende zoekopdracht herstructureren, zware logica naar backend-workflows verplaatsen, een workload-tier kopen vóór de piek in plaats van ruwe overage erna te betalen. Transparante pass-through-facturering maakt van verbruik een gedeeld dashboard waar jullie beiden naar kijken, en dat is de enige regeling waarin optimalisatiewerk zichzelf verkoopt.
De oplossing: maak platformkosten een pass-through-kost
Pass-through-kosten zijn uitgaven die je bureau namens een klant betaalt — leveranciersabonnementen, gebruiksrekeningen, licentiekosten — die aan de klant worden doorgefactureerd, hetzij tegen kostprijs, hetzij met een behandelingsmarkup. Het concept is standaard in bureauadministratie: de eigen kosten van de klant stromen door je boeken zonder jouw inkomen te worden. Toegepast op no-code-platforms zijn er drie werkbare modellen. Kies er per klant één, schriftelijk, voordat de app live gaat.
Model 1: de klant houdt het leveranciersaccount aan en betaalt rechtstreeks. De klant maakt zijn eigen Bubble- of Webflow-account aan, voegt zijn eigen kaart toe en is eigenaar van het plan, de tiers en de overages. Je bureau wordt uitgenodigd als collaborator of guest editor. Dit is de schoonste regeling — de metered factuur raakt je boeken nooit — en het is de juiste standaard voor grotere klanten met hun eigen financiële functie. Het bekende nadeel: klanten investeren soms te weinig in hun plantier om geld te besparen, wat prestatieknelpunten en limit-hit-storingen creëert die jij vervolgens moet diagnosticeren en uitleggen. Als je dit model kiest, zet dan een aanbeveling voor een minimale tier in de overdrachtsdocumentatie en een clausule dat draaien onder die tier op risico van de klant is.
Model 2: het bureau betaalt en factureert door tegen kostprijs plus een markup. Jij houdt het leveranciersaccount aan, betaalt de platformfactuur met je eigen kaart en factureert de klant elke maand voor de exacte platformkosten plus een behandelingsvergoeding — doorgaans 10 tot 20 procent van de pass-through, het bereik dat de meeste bureaus gebruiken om leveranciersbeheer, reconciliatie en het voorschieten van cash te dekken. Dit model past bij kleinere klanten die één factuur en nul leveranciersadministratie willen. Je contract moet het markup-percentage, de factureringsfrequentie en — cruciaal — dat prijsverhogingen van de leverancier automatisch doorstromen vermelden. Zonder die laatste zin heropent elke Bubble- of Webflow-prijswijziging je prijsstelling.
Model 3: een gebundeld care plan met een gebruikslimiet en een overage-clausule. Je offreert een vast maandelijks retainer dat platformkosten tot een vastgestelde limiet omvat — bijvoorbeeld "omvat het Growth-plan plus tot $150 per maand aan workload-overages" — met alles boven de limiet doorgefactureerd tegen kostprijs plus markup. Dit geeft de klant budgetvoorspelbaarheid in normale maanden terwijl piekrisico blijft waar het hoort. De limiet moet zowel de plantier als een dollar-overagetoelage noemen; "hosting inbegrepen" zonder getallen is Model 0, de val waaruit je probeert te ontsnappen.
Welk model je ook kiest, vijf clausules horen in de statement of work: wie het leveranciersaccount houdt en wiens kaart geregistreerd staat; wie overages en tier-upgrades betaalt, en boven welke dollar-drempel je schriftelijke goedkeuring nodig hebt voordat je een tier koopt; het markup-percentage op doorgefactureerde kosten; een maandelijks gebruiksrapport dat je met de factuur meestuurt, met toelage, verbruik en trend; en de bevestiging van de klant dat wijzigingen in de leverancierslijstprijs doorstromen zonder contractwijziging. Die vijfde clausule is degene die bureaus vergeten en degene die ze later het hardst nodig hebben.
Boek het goed: vergoedingen zijn niet je omzet
Zodra platformkosten door je bureau stromen, moet de boekhouding ze zichtbaar gescheiden houden van wat je daadwerkelijk verdient. Stel dat Bubble $300 van je kaart afschrijft voor de overage van een klant in oktober — één miljoen extra units tegen $0,30 per duizend — en je factureert de klant $345 door: de $300 tegen kostprijs plus een behandelingsvergoeding van 15 procent. Je werkelijke inkomen uit die factuur is $45, niet $345. De volledige $345 als omzet boeken overdrijft je omzet, blaast elke op omzet gebaseerde belasting- of waarderingsberekening op, en maakt een latere terugbetaling of credit een omzetterugboeking in plaats van wat het werkelijk is: geld van de klant dat erdoorheen stroomt.
De boekhoudnorm is het ermee eens. Onder ASC 606 vraagt het principal-versus-agent-kader of je de dienst beheert voordat deze aan de klant wordt overgedragen. Je beheert Bubble's rekenkracht of Webflow's bandbreedte niet — de leverancier doet dat — dus op doorgefactureerde platformkosten is je bureau een agent, en de juiste presentatie is netto: de markup als vergoedingsinkomen, met de vergoeding die doorloopt via gematchte pass-through-regels. Concreet: houd twee paren rekeningen aan: pass-through-omzet gematcht tegen pass-through-kosten, en vergoedingsinkomen dat op zichzelf staat. Het pass-through-paar zou elke maand ruwweg op nul moeten uitkomen, op timing na; de markup leeft in vergoedingsinkomen waar je marges worden gemeten.
Hier is hoe dat eruitziet als plain-text accounting. Het bureau betaalt Bubble's overage van $300 met zijn eigen kaart en factureert de klant vervolgens $345:
2026-10-01 open Assets:Checking:Operating USD
2026-10-01 open Assets:Receivable:Client-Acme USD
2026-10-01 open Expenses:Passthrough:Bubble-WU USD
2026-10-01 open Income:Passthrough-Reimbursement USD
2026-10-01 open Income:Fees:Hosting-Markup USD
2026-10-31 * "Bubble" "October WU overage, client Acme app, 1M units at 0.30 per 1K"
Expenses:Passthrough:Bubble-WU 300.00 USD
Assets:Checking:Operating -300.00 USD
2026-10-31 * "Acme Corp" "October platform reimbursement plus 15 percent hosting admin fee"
Assets:Receivable:Client-Acme 345.00 USD
Income:Passthrough-Reimbursement -300.00 USD
Income:Fees:Hosting-Markup -45.00 USDLoop de logica door. De eerste transactie boekt de leverancierskosten als pass-through-kost, niet als je eigen softwarekosten — het parkeren in gewone bedrijfskosten is de fout die je kostenbasis opgeblazen en je marges dun laat lijken. De tweede transactie splitst de klantfactuur: $300 wordt verrekend tegen de vergoedingsregel, die met de kost tegen nul wegvalt, en alleen de $45 markup landt in vergoedingsinkomen. Als de klant de overage betwist of Bubble een credit verstrekt, raakt de aanpassing het pass-through-paar en beweegt je gerapporteerde omzet nooit. De docs behandelen dit soort rekeningstructuurpatronen dieper, en Fava toont het pass-through-paar als een eigen segment, zodat je elke maand in één oogopslag kunt bevestigen dat het op nul uitkomt.
Twee boekhoudgewoonten laten dit beklijven. Ten eerste: reconcileer platformkosten per klant elke maand, tegen zowel de leveranciersfactuur als je doorfacturering — workload-dashboards wijken vaker af van facturen dan je zou verwachten, en de maand die je overslaat is de maand waarin een tier ongemerkt werd verlengd. Ten tweede: laat het platformsaldo van een klant nooit over kwartalen heen op je kaart staan; factureer doorfactureringen maandelijks met dezelfde betalingsvoorwaarden als je vergoedingen, want een niet-doorgefactureerde overage van $600 die in je kosten veroudert, is een renteloze lening die je nooit hebt toegezegd.
Je volgende stap: audit de contracten die je al hebt getekend
Pak deze week je huidige master agreements en statements of work erbij en zoek naar de zin die dit risico creëert: elke variant van "hosting inbegrepen" gekoppeld aan een vast getal. Controleer voor elk daarvan welk van de drie modellen het werkelijk beschrijft — klant betaalt, doorfacturering met markup, of care plan met limiet — en of de vijf clausules aanwezig zijn: accounthouder, overage-verantwoordelijkheid, markup-percentage, maandelijkse gebruiksrapportage en automatische doorstroming van leveranciersprijswijzigingen. De meeste bureaus vinden minstens één klant op een ongecapte bundel en minstens één contract dat niets zegt over prijswijzigingen.
Los ze dan op in vernieuwingsvolgorde, te beginnen met de klant wiens app het snelst groeit — daar landt de volgende piek. Verplaats nieuwe builds vanaf dag één naar door de klant aangehouden accounts of expliciete doorfactureringsvoorwaarden, zet het gebruiksdashboard op de maandfactuur, en laat de metered factuur doen wat die hoort te doen: stijgen en dalen met het succes van de klant, op het budget van de klant, terwijl jouw marge de jouwe blijft.
