L'aplicació del teu client acaba de tenir el seu millor mes de la història. Els registres s'han triplicat, els fluxos de treball que vas construir funcionen a ple rendiment i el fundador està encantat. Llavors arriba la factura de la plataforma: dos milions d'unitats de càrrega per sobre de l'assignació del pla, facturades a trenta cèntims per cada mil. Això és un excés de 600 $ a més d'un pla de 119 $ — i si el teu contracte diu "allotjament inclòs" dins d'una tarifa mensual fixa, aquests 600 $ surten del teu marge, no del pressupost del client. El seu èxit acaba de convertir-se en la teva pèrdua, i res en el teu abast del treball ho havia previst.
Aquest és el risc de preus definitori de gestionar una agència de no-codi el 2026. Bubble factura per consum, Webflow mesura l'amplada de banda i el volum de contingut, i tots dos revisen els preus periòdicament. Una tarifa fixa pretén que aquests costos siguin predictibles. No ho són. Les agències que sobreviuen a això tracten la despesa de plataforma pel que realment és: un cost repercutit que flueix del proveïdor, a través dels teus llibres, fins al client — amb els teus ingressos reals sent el marge i la quota de gestió, mai el reembossament en si.
Com et factura Bubble realment el 2026
Els preus destacats de Bubble semblen moderats. Amb facturació anual, els plans web van dels 29 $ al mes per a Starter, 119 $ per a Growth i 349 $ per a Team, amb un nivell gratuït a 0 $ i Enterprise amb preu a consultar. La facturació mensual costa més: 32 $, 134 $ i 399 $ respectivament. Però la quota del pla és la part més petita de la majoria de factures de producció. El comptador real és la unitat de càrrega.
Cada pla de pagament inclou una assignació mensual d'unitats de càrrega: 175.000 unitats a Starter, 250.000 a Growth i 500.000 a Team. El pla gratuït inclou 50.000 però no pot desplegar una aplicació en línia. Una unitat de càrrega mesura el treball del servidor — cerques a la base de dades, execucions de fluxos de treball, crides a API, càrregues de pàgina, operacions amb fitxers — i el consum varia enormement segons l'operació. Una càrrega de pàgina simple costa aproximadament entre mig i dues unitats; una sola cerca complexa pot costar de 10 a 50. Una aplicació amb fluxos de treball molt actius o cerques no optimitzades pot esgotar una assignació de Starter molt abans que el seu trànsit sembli impressionant.
Quan s'esgota l'assignació, la tarifa d'excés sense cap nivell addicional és de 0,30 $ per cada 1.000 unitats. Un milió d'unitats addicionals en un mes — fàcil per a una aplicació en creixement amb fluxos de treball de backend intensius — costa 300 $. Els nivells de càrrega precomprada redueixen substancialment la tarifa per unitat, fins a uns 0,10 $ per cada 1.000 al nivell més gran, però has de comprar el nivell abans del pic, i els nivells són un compromís mensual propi.
Tres mecàniques fan això perillós específicament per a les agències. Primer, el consum és genuïnament difícil de predir per endavant; dues aplicacions amb el mateix nombre d'usuaris poden diferir en un ordre de magnitud pel que fa a càrrega segons com estiguin construïts els seus fluxos de treball. Segon, els excessos s'activen per defecte, i Bubble envia un correu electrònic al propietari del compte al 75 per cent i al 100 per cent de l'assignació — però si la teva agència té el compte, aquest correu va a tu, no al client els usuaris del qual van causar el pic. Tercer, desactivar els excessos no limita la factura de manera elegant: l'aplicació queda fora de línia quan arriba al límit fins que es tornen a activar els excessos, es compra un nivell o comença el cicle següent. "El lloc va caure perquè vam arribar a un límit d'ús que ningú vigilava" no és una conversa que vulguis tenir amb un client.
Webflow té la mateixa forma amb comptadors diferents
Webflow no utilitza unitats de càrrega, però els seus preus tenen el mateix perfil de volatilitat des de la perspectiva d'una agència: una quota base modesta més comptadors que es mouen amb l'èxit del client.
El maig del 2026, Webflow va fusionar els seus antics plans de lloc CMS i Business en un únic pla Premium: 25 $ al mes per lloc amb facturació anual (39 $ mensuals), que cobreix 300 pàgines estàtiques, 20.000 elements CMS i 50 GB d'amplada de banda. El pla Basic a 15 $ al mes cobreix un domini personalitzat i 10 GB d'amplada de banda però cap CMS. Qualsevol cosa per sobre de l'amplada de banda inclosa es ven com a complements de pagament, fins a 2,5 terabytes — així que un llançament viral d'un client o un trimestre intens de trànsit d'imatges i vídeo es converteix directament en una factura de Webflow més gran.
I el pla del lloc és només una de tres factures. Els plans d'espai de treball per a la col·laboració en disseny, els seients addicionals de dissenyador, les configuracions regionals addicionals i la capacitat de transaccions de comerç electrònic es facturen tots per separat, a més de la quota per lloc. Un client que demana "només un idioma més" o "accés per a dos editors més" t'està demanant que augmentis una pila mesurada — i si el teu contracte cotitza un únic número mensual pla per "lloc web més allotjament", cada un d'aquests sí redueix el teu marge.
Totes dues plataformes també revisen els preus. Bubble va ajustar els preus de Starter l'octubre del 2026; Webflow va reestructurar tota la seva línia de plans de lloc a mitjan any. Qualsevol cotització fixa de diversos mesos que incorpori els preus de plataforma d'avui és una aposta que el proveïdor es quedarà quiet. Aquesta aposta ha estat perdent durant anys.
L'error contractual: agrupar costos mesurats en una tarifa fixa
El mode de fallada és gairebé sempre la mateixa frase, enterrada en una proposta o un acord marc de serveis: una tarifa mensual fixa que "inclou l'allotjament". Es llegeix com a simplicitat per al client. A la pràctica, converteix la teva agència en l'asseguradora de la volatilitat del proveïdor — cobres una prima fixa i absorbeixes un desavantatge mesurat il·limitat.
Els informes del sector sobre construccions d'agències situen les quotes típiques de projectes de Bubble entre 20.000 $ i 250.000 $, i assenyalen la trampa específica de marge: quan lliures una aplicació de client i el negoci del client té èxit, el consum augmenta, i o bé el client paga més del que mai havia pressupostat o l'agència absorbeix l'augment. El preu fix sobre un abast vague ja és la causa més comuna de disputes entre agència i client en serveis de programari en general; afegir una factura mesurada de tercers dins del preu fix converteix cada pic d'ús en una renegociació.
La mateixa trampa apareix un nivell més avall en el treball d'IA i automatització, on les agències que agrupen costos d'API i de tokens en quotes fixes descobreixen que un canvi de preu del proveïdor es converteix en la seva pèrdua durant la nit. La despesa de plataforma es comporta exactament com la despesa de tokens: mesurada per tercers, impulsada pel client i fora del teu control. Els costos amb aquestes tres propietats no pertanyen dins d'una tarifa fixa. Pertanyen en una clàusula de repercussió.
Hi ha un segon cost més silenciós de l'agrupació: amaga els números al client. Un client que mai veu la tendència d'unitats de càrrega no té cap raó per aprovar el treball d'optimització que la reduiria — reestructurar una cerca ineficient, traslladar la lògica pesada als fluxos de treball de backend, comprar un nivell de càrrega abans del pic en lloc de pagar l'excés brut després. La facturació transparent per repercussió converteix l'ús en un tauler compartit que tots dos vigileu, que és l'únic arranjament on el treball d'optimització es ven sol.
La solució: convertir la despesa de plataforma en un cost repercutit
Els costos repercutits són despeses que la teva agència paga en nom d'un client — subscripcions de proveïdors, factures d'ús, quotes de llicència — que es facturen de tornada al client, ja sigui a cost o amb un marge de gestió. El concepte és estàndard en la comptabilitat d'agències: els costos propis del client flueixen a través dels teus llibres sense convertir-se en els teus ingressos. Aplicat a les plataformes de no-codi, hi ha tres models viables. Tria'n un per client, per escrit, abans que l'aplicació estigui en línia.
Model 1: el client té el compte del proveïdor i paga directament. El client crea el seu propi compte de Bubble o Webflow, afegeix la seva pròpia targeta i és propietari del pla, els nivells i els excessos. La teva agència és convidada com a col·laboradora o editora convidada. Aquest és l'arranjament més net — la factura mesurada mai toca els teus llibres — i és el valor predeterminat adequat per a clients més grans amb la seva pròpia funció financera. El desavantatge conegut: de vegades els clients inverteixen poc en el nivell del seu pla per estalviar diners, cosa que crea colls d'ampolla de rendiment i caigudes per límit assolit que llavors has de diagnosticar i explicar. Si tries aquest model, posa una recomanació de nivell mínim als documents de lliurament i una clàusula que estableixi que operar per sota és a risc del client.
Model 2: l'agència paga i refactura a cost més un marge. Tu tens el compte del proveïdor, pagues la factura de la plataforma amb la teva pròpia targeta i factures al client cada mes la despesa exacta de plataforma més una quota de gestió — típicament del 10 al 20 per cent de la repercussió, el rang que utilitzen la majoria d'agències per cobrir la gestió de proveïdors, la conciliació i l'avançament d'efectiu. Aquest model s'adapta a clients més petits que volen una sola factura i zero administració de proveïdors. El teu contracte ha d'especificar el percentatge de marge, la periodicitat de facturació i — críticament — que els augments de preus del proveïdor es repercuteixen automàticament. Sense aquesta última frase, cada revisió de preus de Bubble o Webflow reobre la teva cotització.
Model 3: un pla de manteniment agrupat amb un límit d'ús i una clàusula d'excés. Cotitzes una quota mensual fixa que inclou la despesa de plataforma fins a un límit declarat — per exemple, "inclou el pla Growth més fins a 150 $ al mes en excessos de càrrega" — amb qualsevol cosa per sobre del límit facturada a cost més marge. Això dóna al client predictibilitat pressupostària per als mesos normals mentre manté el risc de pics on pertoca. El límit ha de nomenar tant el nivell del pla com una assignació d'excés en dòlars; "inclou allotjament" sense números és el Model 0, la trampa de la qual intentes escapar.
Sigui quin sigui el model que triïs, cinc clàusules pertanyen a la declaració de treball: qui té el compte del proveïdor i quina targeta hi ha registrada; qui paga els excessos i les millores de nivell, i per sobre de quin llindar en dòlars necessites aprovació per escrit abans de comprar un nivell; el percentatge de marge sobre la despesa refacturada; un informe mensual d'ús que envies amb la factura, mostrant l'assignació, el consum i la tendència; i el reconeixement del client que els canvis de preu de llista del proveïdor es repercuteixen sense una esmena del contracte. Aquesta cinquena clàusula és la que les agències obliden i la que després necessiten més.
Registra-ho bé: els reembossaments no són els teus ingressos
Un cop la despesa de plataforma flueix a través de la teva agència, la comptabilitat ha de mantenir-la visiblement separada del que realment guanyes. Suposem que Bubble cobra a la teva targeta 300 $ per l'excés d'octubre d'un client — un milió d'unitats addicionals a 0,30 $ per cada mil — i tu refactures al client 345 $: els 300 $ a cost més una quota de gestió del 15 per cent. Els teus ingressos reals d'aquesta factura són 45 $, no 345 $. Enregistrar els 345 $ complets com a ingressos exagera la teva línia superior, infla qualsevol càlcul d'impostos o valoració basat en ingressos i fa que un reembossament o crèdit posterior sigui una reversió d'ingressos en lloc del que realment és: diners del client que passen de llarg.
La norma comptable hi està d'acord. Sota l'ASC 606, el marc de principal-versus-agent pregunta si controles el servei abans que es transfereixi al client. No controles la computació de Bubble ni l'amplada de banda de Webflow — el proveïdor sí — així que sobre la despesa de plataforma refacturada la teva agència és un agent, i la presentació correcta és neta: el marge com a ingressos per quotes, amb el reembossament passant per línies de repercussió aparellades. Concretament, mantén dos parells de comptes: ingressos per repercussió aparellats amb despesa per repercussió, i ingressos per quotes per si sols. El parell de repercussió hauria de netejar aproximadament a zero cada mes, amb marge per temporització; el marge viu en els ingressos per quotes on es mesuren els teus marges.
Aquí tens com es veu això com a comptabilitat de text pla. L'agència paga l'excés de 300 $ de Bubble amb la seva pròpia targeta i després factura al client 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 USDRecorre la lògica. La primera transacció registra el càrrec del proveïdor com a despesa per repercussió, no com el teu propi cost de programari — aparcar-lo en despeses operatives ordinàries és l'error que fa que la teva base de costos sembli inflada i els teus marges semblin prims. La segona transacció divideix la factura del client: els 300 $ es compensen contra la línia de reembossament, que neteja amb la despesa a zero, i només els 45 $ de marge arriben als ingressos per quotes. Si el client disputa l'excés o Bubble emet un crèdit, l'ajust afecta el parell de repercussió i els teus ingressos reportats no es mouen mai. La documentació cobreix patrons d'estructura de comptes com aquest amb més profunditat, i Fava mostra el parell de repercussió com la seva pròpia porció perquè puguis confirmar que neteja a zero d'un cop d'ull cada mes.
Dos hàbits comptables fan que això es mantingui. Primer, concilia la despesa de plataforma per client cada mes, contra la factura del proveïdor i la teva refacturació — els taulers de càrrega divergeixen de les factures més sovint del que esperaries, i el mes que t'ho saltes és el mes que es va renovar un nivell sense que ningú se n'adonés. Segon, no deixis mai que el saldo de plataforma d'un client passi als teus comptes d'un trimestre a l'altre; factura les refacturacions mensualment amb els mateixos terminis de pagament que les teves quotes, perquè un excés de 600 $ no refacturat que envelleix a les teves despeses és un préstec sense interessos que mai vas acceptar fer.
El teu proper pas: audita els contractes que ja has signat
Recupera els teus acords marc actuals i declaracions de treball aquesta setmana i busca la frase que crea aquest risc: qualsevol variant d'"allotjament inclòs" adjunta a un número fix. Per a cada una, comprova quin dels tres models descriu realment — client-paga, refacturació-amb-marge o pla de manteniment amb límit — i si hi són les cinc clàusules: titular del compte, responsabilitat d'excessos, percentatge de marge, informes mensuals d'ús i repercussió automàtica dels canvis de preu del proveïdor. La majoria d'agències troben almenys un client amb un paquet sense límit i almenys un contracte sense esment de la revisió de preus.
Després arregla'ls per ordre de renovació, començant pel client l'aplicació del qual creix més ràpidament — és allà on aterrarà el proper pic. Passa les noves construccions a comptes en mans del client o a termes de refacturació explícits des del primer dia, posa el tauler d'ús a la factura mensual i deixa que la factura mesurada faci el que ha de fer: pujar i baixar amb l'èxit del client, amb el pressupost del client, mentre el teu marge segueix sent teu.
