Застосунок вашого клієнта щойно пережив найкращий місяць в історії. Реєстрації потроїлися, побудовані вами робочі процеси працюють бездоганно, і засновник у захваті. А потім надходить рахунок від платформи: два мільйони робочих одиниць понад ліміт тарифу, тарифіковані за тридцять центів за тисячу. Це перевитрата в $600 понад тариф у $119 — і якщо ваш договір каже «хостинг включено» у складі фіксованої місячної плати, ці $600 виходять із вашої маржі, а не з бюджету клієнта. Їхній успіх щойно став вашим збитком, і ніщо у вашому обсязі робіт цього не передбачало.
Це визначальний ціновий ризик для no-code агенції у 2026 році. Bubble тарифікує за споживання, Webflow вимірює пропускну здатність і обсяг вмісту, і обидві періодично переглядають ціни. Фіксована плата вдає, що ці витрати передбачувані. Вони не є такими. Агенції, які це переживають, ставляться до витрат на платформу як до того, чим вони насправді є: транзитної витрати, що тече від постачальника, через ваші книги, до клієнта — причому вашим реальним доходом є націнка та плата за управління, а ніколи не саме відшкодування.
Як Bubble насправді виставляє вам рахунки у 2026 році
Заявлені ціни Bubble виглядають стримано. При річній оплаті веб-тарифи коштують $29 на місяць за Starter, $119 за Growth і $349 за Team, з безкоштовним рівнем за $0 і Enterprise за запитом. Місячна оплата коштує дорожче: $32, $134 і $399 відповідно. Але плата за тариф — найменша частина більшості виробничих рахунків. Справжній лічильник — це робоча одиниця.
Кожен платний тариф включає місячний ліміт робочих одиниць: 175 000 одиниць на Starter, 250 000 на Growth і 500 000 на Team. Безкоштовний тариф включає 50 000, але не дозволяє розгорнути робочий застосунок. Робоча одиниця вимірює серверну роботу — пошук у базі даних, запуск робочих процесів, виклики API, завантаження сторінок, файлові операції — і споживання різко відрізняється залежно від операції. Просте завантаження сторінки коштує приблизно від половини до двох одиниць; один складний пошук може коштувати від 10 до 50. Застосунок із частими робочими процесами чи неоптимізованими пошуками може спалити ліміт Starter задовго до того, як його трафік виглядатиме вражаючим.
Коли ліміт вичерпано, ставка перевитрати без будь-якого додаткового рівня становить $0.30 за 1 000 одиниць. Один мільйон додаткових одиниць на місяць — легко для зростаючого застосунку з важкими серверними робочими процесами — коштує $300. Попередньо придбані рівні робочих одиниць суттєво знижують ставку за одиницю, аж до близько $0.10 за 1 000 на найбільшому рівні, але ви маєте купити рівень до стрибка, і рівні самі по собі є місячним зобов'язанням.
Три механізми роблять це особливо підступним саме для агенцій. По-перше, споживання справді важко передбачити заздалегідь; два застосунки з ідентичною кількістю користувачів можуть відрізнятися на порядок за навантаженням залежно від того, як побудовані їхні робочі процеси. По-друге, перевитрати вмикаються за замовчуванням, і Bubble надсилає власнику акаунта листи на 75 і 100 відсотках ліміту — але якщо акаунт тримає ваша агенція, цей лист іде до вас, а не до клієнта, чиї користувачі спричинили стрибок. По-третє, вимкнення перевитрат не обмежує рахунок елегантно: застосунок вимикається, коли досягає ліміту, доки перевитрати не буде знову ввімкнено, рівень не куплено або не почнеться наступний цикл. «Сайт впав, бо ми досягли ліміту споживання, за яким ніхто не стежив» — це не та розмова, яку ви хочете мати з клієнтом.
Webflow має ту саму форму з іншими лічильниками
Webflow не використовує робочі одиниці, але його ціноутворення має той самий профіль волатильності з погляду агенції: скромна базова плата плюс лічильники, що рухаються разом з успіхом клієнта.
У травні 2026 року Webflow об'єднав свої старі тарифи сайту CMS і Business в єдиний тариф Premium: $25 на місяць за сайт при річній оплаті ($39 щомісяця), що охоплює 300 статичних сторінок, 20 000 елементів CMS і 50 ГБ пропускної здатності. Тариф Basic за $15 на місяць охоплює власний домен і 10 ГБ пропускної здатності, але без CMS взагалі. Усе понад включену пропускну здатність продається як платні додатки, аж до 2,5 терабайт — тож вірусний запуск клієнта чи важкий квартал трафіку зображень і відео безпосередньо перетворюється на більший рахунок Webflow.
І тариф сайту — це лише один із трьох рахунків. Тарифи робочого простору для дизайнерської співпраці, додаткові місця дизайнерів, додаткові локалі та потужність транзакцій електронної комерції тарифікуються окремо, понад плату за сайт. Клієнт, який просить «лише одну мову» або «доступ для ще двох редакторів», просить вас збільшити лічильниковий стек — і якщо ваш договір називає одну плоску місячну суму за «сайт плюс хостинг», кожне з цих «так» зменшує вашу маржу.
Обидві платформи також переглядають ціни. Bubble скоригував ціни Starter у жовтні 2026 року; Webflow перебудував усю лінійку тарифів сайту посеред року. Будь-яка фіксована котировка на кілька місяців, що вбудовує сьогоднішні ціни платформи, — це ставка на те, що постачальник не зрушить з місця. Ця ставка програє вже роками.
Помилка в договорі: включення лічильникових витрат у фіксовану плату
Режим відмови майже завжди — те саме речення, поховане в пропозиції чи головному договорі про надання послуг: фіксована місячна плата, що «включає хостинг». Для клієнта це читається як простота. На практиці це робить вашу агенцію страховиком волатильності постачальника — ви збираєте фіксовану премію й абсорбуєте необмежений лічильниковий збиток.
Галузеві звіти про проєкти агенцій оцінюють типові гонорари за проєкти Bubble від $20 000 до $250 000 і відзначають конкретну пастку маржі: коли ви постачаєте клієнтський застосунок і бізнес клієнта досягає успіху, споживання зростає, і або клієнт платить більше, ніж ніколи не планував, або агенція абсорбує збільшення. Фіксована ціна за нечіткого обсягу — уже найпоширеніше джерело спорів між агенцією та клієнтом у сфері програмних послуг загалом; додавання лічильникового рахунку третьої сторони всередину фіксованої ціни перетворює кожен стрибок використання на переговори.
Та сама пастка з'являється на рівень нижче в роботі зі штучним інтелектом та автоматизацією, де агенції, які включають витрати на API та токени в плоскі ретейнери, виявляють, що зміна ціни постачальника за ніч стає їхнім збитком. Витрати на платформу поводяться точно як витрати на токени: тарифікуються третьою стороною, керуються клієнтом і поза вашим контролем. Витрати з цими трьома властивостями не належать до фіксованої плати. Вони належать до транзитного положення.
Є й друга, тихіша ціна включення: воно приховує цифри від клієнта. Клієнт, який ніколи не бачить тренду робочих одиниць, не має причин схвалювати оптимізаційну роботу, яка його зменшила б — реструктуризацію марнотратного пошуку, перенесення важкої логіки в серверні робочі процеси, купівлю рівня робочих одиниць до стрибка замість сплати сирої перевитрати після нього. Прозоре транзитне виставлення рахунків перетворює використання на спільну панель, за якою ви обидва стежите, і це єдина домовленість, де оптимізаційна робота продає себе сама.
Рішення: зробіть витрати на платформу транзитною витратою
Транзитні витрати — це витрати, які ваша агенція сплачує від імені клієнта — підписки постачальників, рахунки за використання, ліцензійні збори — і які виставляються клієнту назад, або за собівартістю, або з націнкою за обробку. Концепція стандартна в бухгалтерії агенцій: власні витрати клієнта проходять через ваші книги, не стаючи вашим доходом. У застосуванні до no-code платформ є три робочі моделі. Виберіть одну на клієнта, письмово, до запуску застосунку.
Модель 1: клієнт тримає акаунт постачальника й платить напряму. Клієнт створює власний акаунт Bubble чи Webflow, додає власну картку й володіє тарифом, рівнями та перевитратами. Вашу агенцію запрошують як співробітника чи гостьового редактора. Це найчистіша домовленість — лічильниковий рахунок ніколи не торкається ваших книг — і це правильний варіант за замовчуванням для більших клієнтів із власною фінансовою функцією. Відомий недолік: клієнти іноді недоінвестують у свій тариф, щоб заощадити, що створює вузькі місця продуктивності та відмови через досягнення лімітів, які вам потім доводиться діагностувати й пояснювати. Якщо ви вибираєте цю модель, додайте рекомендацію мінімального тарифу до документів передачі й положення про те, що робота нижче нього — на ризик клієнта.
Модель 2: агенція платить і перевиставляє за собівартістю плюс націнка. Ви тримаєте акаунт постачальника, платите рахунок платформи зі своєї картки й щомісяця виставляєте клієнту рахунок на точну суму витрат на платформу плюс плату за обробку — зазвичай 10–20 відсотків транзитної суми, діапазон, який використовує більшість агенцій для покриття управління постачальниками, звірки та авансування коштів. Ця модель підходить меншим клієнтам, які хочуть один рахунок і нуль адміністрування постачальників. Ваш договір має вказувати відсоток націнки, періодичність виставлення рахунків і — критично — що підвищення цін постачальника проходять автоматично. Без цього останнього речення кожен перегляд цін Bubble чи Webflow відкриває ваше ціноутворення заново.
Модель 3: пакетний план підтримки з обмеженням використання та положенням про перевитрати. Ви називаєте плоский місячний ретейнер, що включає витрати на платформу до зазначеного ліміту — наприклад, «включає тариф Growth плюс до $150 на місяць перевитрат робочих одиниць» — а все понад ліміт виставляється за собівартістю плюс націнка. Це дає клієнту передбачуваність бюджету для звичайних місяців, зберігаючи ризик стрибків там, де йому місце. Ліміт має називати і рівень тарифу, і доларовий допуск перевитрат; «включає хостинг» без цифр — це Модель 0, пастка, від якої ви тікаєте.
Яку б модель ви не вибрали, п'ять положень належать до технічного завдання: хто тримає акаунт постачальника і чия картка збережена; хто платить за перевитрати й підвищення рівнів і вище якого доларового порогу вам потрібне письмове схвалення перед купівлею рівня; відсоток націнки на перевиставлені витрати; щомісячний звіт про використання, який ви надсилаєте з рахунком, показуючи ліміт, споживання й тренд; і визнання клієнтом того, що зміни прайс-листа постачальника проходять без поправки до договору. Це п'яте положення — те, яке агенції забувають і яке їм пізніше найбільше потрібне.
Обліковуйте правильно: відшкодування — це не ваш дохід
Коли витрати на платформу течуть через вашу агенцію, бухгалтерія має тримати їх видимо окремо від того, що ви насправді заробляєте. Припустімо, Bubble стягує з вашої картки $300 за жовтневу перевитрату клієнта — один мільйон додаткових одиниць за $0.30 за тисячу — і ви перевиставляєте клієнту $345: $300 за собівартістю плюс 15 відсотків плати за обробку. Ваш реальний дохід від цього рахунку — $45, а не $345. Проведення всіх $345 як доходу завищує ваш валовий дохід, роздуває будь-які розрахунки податку чи оцінки на основі доходу й робить подальше повернення чи кредит сторно доходу замість того, чим воно насправді є: гроші клієнта, що проходять наскрізь.
Стандарт бухгалтерського обліку погоджується. За ASC 606 рамка «принципал чи агент» запитує, чи контролюєте ви послугу до її передачі клієнту. Ви не контролюєте обчислювальні потужності Bubble чи пропускну здатність Webflow — їх контролює постачальник — тож на перевиставлених витратах на платформу ваша агенція є агентом, і правильне подання — нетто: націнка як дохід від гонорарів, а відшкодування проходить через зіставлені транзитні рядки. Конкретно, тримайте дві пари рахунків: транзитний дохід, зіставлений із транзитними витратами, і дохід від гонорарів окремо. Транзитна пара має зводитися приблизно до нуля щомісяця, з точністю до часу; націнка живе в доході від гонорарів, де вимірюються ваші маржі.
Ось як це виглядає в обліку звичайного тексту. Агенція платить $300 перевитрати Bubble зі своєї картки, а потім виставляє клієнту рахунок на $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 USDПройдіться логікою. Перша транзакція записує плату постачальника як транзитну витрату, а не як вашу власну витрату на програмне забезпечення — розміщення її серед звичайних операційних витрат є помилкою, що робить вашу базу витрат роздутою, а маржу — тонкою. Друга транзакція розділяє рахунок клієнта: $300 зводяться проти рядка відшкодування, який чиститься проти витрати до нуля, і лише $45 націнки потрапляє в дохід від гонорарів. Якщо клієнт оспорює перевитрату або Bubble випускає кредит, коригування влучає в транзитну пару, і ваш задекларований дохід ніколи не рухається. Документація висвітлює шаблони структури рахунків на кшталт цього глибше, а Fava відображає транзитну пару як окремий зріз, тож ви можете підтвердити, що вона зводиться до нуля, одним поглядом щомісяця.
Дві бухгалтерські звички роблять це стійким. По-перше, звіряйте витрати на платформу за кожним клієнтом щомісяця, проти і рахунку постачальника, і вашого перевиставлення — панелі навантаження розходяться з рахунками частіше, ніж ви очікували б, і місяць, який ви пропустили, — це місяць, коли рівень поновився непоміченим. По-друге, ніколи не дозволяйте платформному балансу клієнта висіти на вашій картці через квартали; виставляйте перевиставлення щомісяця з тими самими умовами оплати, що й ваші гонорари, бо неперевиставлена перевитрата в $600, що старіє у ваших витратах, — це безвідсоткова позика, яку ви ніколи не погоджувалися давати.
Ваш наступний крок: перевірте договори, які ви вже підписали
Дістаньте цього тижня ваші чинні головні договори й технічні завдання та пошукайте речення, що створює цей ризик: будь-який варіант «хостинг включено», прикріплений до фіксованої цифри. Для кожного перевірте, яку з трьох моделей він насправді описує — клієнт платить, перевиставлення з націнкою чи обмежений план підтримки — і чи присутні п'ять положень: власник акаунта, відповідальність за перевитрати, відсоток націнки, щомісячна звітність про використання й автоматичне проходження змін цін постачальника. Більшість агенцій знаходять принаймні одного клієнта на необмеженому пакеті й принаймні один договір, що мовчить про перегляд цін.
Потім виправте їх у порядку поновлення, починаючи з клієнта, чий застосунок зростає найшвидше — саме там приземлиться наступний стрибок. Переведіть нові збірки на клієнтські акаунти чи явні умови перевиставлення з першого дня, додайте панель використання до щомісячного рахунку й дозвольте лічильниковому рахунку робити те, що він має робити: зростати й падати разом з успіхом клієнта, за бюджетом клієнта, поки ваша маржа залишається вашою.
