Приложение вашего клиента только что пережило лучший месяц за всю свою историю. Регистрации выросли втрое, созданные вами рабочие процессы работают как часы, основатель в восторге. А потом приходит счёт от платформы: два миллиона рабочих единиц сверх лимита тарифа по тридцать центов за тысячу. Это $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, стареющий в ваших расходах, — это беспроцентный кредит, который вы никогда не соглашались выдать.
Ваш следующий шаг: проверьте контракты, которые вы уже подписали
Достаньте на этой неделе ваши действующие рамочные договоры и технические задания и поищите предложение, которое создаёт этот риск: любой вариант «хостинг включён», привязанный к фиксированной цифре. Для каждого проверьте, какую из трёх моделей он на самом деле описывает — платит клиент, перевыставление с наценкой или план обслуживания с лимитом, — и присутствуют ли пять оговорок: держатель аккаунта, ответственность за сверхлимит, процент наценки, ежемесячная отчётность об использовании и автоматическое прохождение изменений цен поставщика. Большинство агентств обнаруживают хотя бы одного клиента на неограниченном пакете и хотя бы один контракт, который умалчивает о пересмотре цен.
Затем исправьте их в порядке продления, начиная с клиента, чьё приложение растёт быстрее всех — именно там случится следующий скачок. Переводите новые сборки на аккаунты, принадлежащие клиентам, или на явные условия перевыставления с первого дня, включайте панель использования в ежемесячный счёт и позвольте тарифицируемому счёту делать то, что он должен: расти и падать вместе с успехом клиента, за счёт бюджета клиента, пока ваша маржа остаётся вашей.
