Юнит-экономика для инженера: выручка, затраты, окупаемость, точка безубыточности

Есть разговор, который случается с самостоятельным инженером на второй год. «Оборот вырос в полтора раза». — «А денег стало больше?» — «Странно, но нет. Даже меньше, и работаю я больше». Так бывает, когда бизнес меряют одним агрегатом: годовой оборот — как средняя латентность по всему сервису, число есть, решения из него не следуют. Чтобы следовали, надо профилировать по запросу; в деньгах то же самое — разложить дело на одну повторяемую сделку и посмотреть, приносит ли она прибыль сама по себе. Это и есть юнит-экономика: модное слово поверх старого CVP-анализа (cost-volume-profit) из управленческого учёта, к которому стартап-жаргон добавил CAC, LTV и когорты. Половины две: выгодна ли одна сделка и сколько таких сделок нужно, чтобы жить.

Рамка трека — прочитайте до того, как считать. Здесь нет юридических, налоговых и бухгалтерских консультаций и нет ни одной «настоящей» цифры: все числа в примерах — заглушки в условных единицах (у.е.). Никаких «рыночных вилок», «нормальных ставок» и «типичных значений оттока» тут нет намеренно: они зависят от страны, ниши, валюты, размера заказчика и даты и устаревают быстрее статьи. Налоги и взносы входят в расчёт как параметр, значение которого называет живой бухгалтер под вашу форму деятельности (самозанятость, ИП, ООО — обзор форм в Договорах), а первоисточники вы проверяете на дату: ФНС России, Госуслуги, портал правовой информации. Правила и цифры меняются; статья из интернета — не источник права. Час бухгалтера дешевле ошибки в годовом расчёте, час юриста — дешевле плохого договора.

1. Юнит: выбор единицы — половина ответа

Юнит-экономика — это прибыль и убыток, посчитанные на одну повторяемую единицу сделки. Не на месяц и не на «весь бизнес»: «эта сделка приносит X у.е. на покрытие постоянных затрат» — или «отнимает X, и чем их больше, тем быстрее я тону». Хороший юнит повторяем, измерим без героизма (данные собираются за минуты, а не расследованием) и оплачиваем. Последнее заваливают чаще всего: инженеры любят считать экономику «фичи» или «зарегистрированного пользователя», за которых никто не платит.

Если моделей две (проекты плюс поддержка) — не смешивайте их в один юнит: считайте две экономики и складывайте только на уровне периода. Смешение — источник самой дорогой ошибки: прибыльное направление годами дотирует убыточное, и вы этого не видите.

2. Выручка: три разных числа, которые все зовут одним словом

Инженер считает выручкой сумму, которую назвал клиенту. Живут же три числа: сумма договора (намерение), признанная выручка (сдано и принято за период) и полученные деньги (пришло на счёт и осталось после комиссий). Между ними — все интересные потери: скидки, спорные правки, комиссии, возвраты, курсовые разницы, отсрочка и иногда неоплата.

Отсюда правило на видное место: юнит-экономика считается по начислению, выживание — по кассе: модель может показывать прекрасную маржу, пока вы не можете заплатить за хостинг, потому что деньги придут через два месяца (Деньги и риски). Чистая выручка юнита для расчётов:

$$R_{\text{нетто}} = S_{\text{счёт}} - \text{скидки} - \text{возвраты} - \text{комиссии} - \text{транзит}$$

Про транзит отдельно: перевыставленные лицензии, железо или работа субподрядчика проходят через вас, но вашей выручкой не являются — маржа в них нулевая или равна оговорённой наценке; гордиться «оборотом в N миллионов», внутри которого 70 процентов чужих лицензий, — гордиться логистикой. Налоги здесь — не строка «минус процент из статьи», а параметр, зависящий от формы деятельности, режима, вида работ и валюты расчётов: берите его у бухгалтера, сверяйте на ФНС, а до этого ставьте заведомо консервативную оценку — она стоит недополученной прибыли, оптимистичная — недостачи, которую нечем закрыть.

3. Затраты: переменные, постоянные, ступенчатые и невидимые

Критерий деления не «важное/мелкое», а зависит ли сумма от объёма. Переменные ($v$) растут с числом юнитов: подрядчик на проект, комиссия эквайринга, оплата API за вызов, поддержка после сдачи. Постоянные ($F$) не зависят от объёма внутри периода: рабочее место, подписки, бухгалтерия, амортизация техники. Ступенчатые постоянны до порога, потом скачок: тариф «до N проектов», второй человек. Граница зависит от горизонта — постоянные затраты это переменные с длинным лагом решения, поэтому считайте экономику на горизонте принимаемого решения.

Ваше время — самая дорогая невидимая статья, потому что не покупается за деньги. Нужны две модели сразу: денежная (вы себе не платите; отвечает «переживу ли месяц») и экономическая (труд по вменённой себестоимости часа, то есть по вашей лучшей альтернативе; отвечает «выгоднее ли это, чем другая работа»). Проект «в плюсе» по деньгам, съедающий время, которое можно было продать дороже, экономически убыточен — так и выглядят «интересные» проекты, уносящие год; методика расчёта пола ставки — в Ценообразовании. Что почти никто не относит на юнит, а надо: пресейл, включая проигранные сделки; гарантию и поддержку (пока идёт гарантийный срок, часы пишутся в этот проект); правки сверх границ (Оценка и границы работ); ожидание доступов; переключение контекста (три параллельных проекта не равны трём последовательным, см. Фокус); ожидаемые потери от неплатежей — при доле проблемных оплат $q$ вычитайте $q \cdot p$ из маржи заранее.

4. Маржинальная прибыль — главное число статьи

Маржинальная прибыль (contribution margin) — то, что остаётся от цены юнита после переменных затрат, то есть вклад одной сделки в покрытие постоянных затрат и в прибыль:

$$CM = p - v, \qquad m = \frac{p - v}{p}$$

где $p$ — чистая цена юнита (§2), $v$ — переменные затраты на юнит, $m$ — маржинальность как доля цены. Это не «прибыль с проекта»: постоянные затраты сюда не входят намеренно — вопрос в том, сколько сделка приносит в общий котёл. Следствия: при $CM < 0$ сделка убыточна сама по себе (больше объёма — больше убыток; лечится ценой, составом работ или отказом, но не усердием), при малом положительном $CM$ вы живы, пока не прервётся поток, а число юнитов до нуля равно ровно $F / CM$.

"""Маржа одной сделки в услугах. ВСЕ ЧИСЛА — ЗАГЛУШКИ в у.е.; ставку налога берите
у бухгалтера, не из статьи. Сложность O(k) по числу категорий часов, память O(k)."""


def deal_margin(price, hours: dict[str, float], hour_cost, subcontract=0.0,
                pass_through=0.0, fee_rate=0.0, tax_rate=0.0) -> dict:
    net = (price - pass_through) * (1 - fee_rate) * (1 - tax_rate)   # транзит — не выручка
    variable = subcontract + sum(hours.values()) * hour_cost   # подряд + ВСЁ ваше время
    return {"нетто": net, "маржа": net - variable, "маржинальность": (net - variable) / net,
            "эффективная_ставка_часа": net / sum(hours.values())}


print(deal_margin(
    price=300_000, hour_cost=1_500, subcontract=30_000, pass_through=40_000,
    fee_rate=0.05, tax_rate=0.07,          # tax_rate — ПАРАМЕТР, а не «примерно как у всех»
    hours={"пресейл": 12, "проигранные_оценки": 9, "разработка": 90, "созвоны": 18,
           "правки_сверх": 14, "ожидание_доступов": 7, "гарантия": 10},
))

Запустите — и на этих заглушках маржа окажется отрицательной, хотя «на глаз» сделка выглядела удачной: 90 часов разработки против 70 часов всего остального плюс комиссии и транзит. В этом и ценность — не в самом вычислении, а в дисциплине: словарь hours заставляет назвать все категории времени. проигранные_оценки, правки_сверх и гарантия — три места, где маржа исчезает тише всего; ещё два — комиссии с транзитом и скидка «за долгосрочность», выданная авансом.

5. Точка безубыточности

Точка безубыточности — объём, при котором маржинальная прибыль ровно покрывает постоянные затраты. Ниже неё вы платите за право работать:

$$Q_{\text{бу}} = \frac{F}{p - v}, \qquad S_{\text{бу}} = \frac{F}{m}, \qquad \text{MoS} = \frac{S - S_{\text{бу}}}{S}$$

$Q_{\text{бу}}$ — в юнитах, $S_{\text{бу}}$ — в деньгах, $\text{MoS}$ (margin of safety) — запас прочности: на какую долю может упасть выручка, прежде чем вы уйдёте в минус.

Критично для одиночки: в $F$ обязан входить ваш собственный «оклад» — то, на что вы живёте; порог без него показывает объём, при котором вы работаете бесплатно, но не голодаете за счёт бизнеса. Считайте два: порог выживания (личный бюджет и обязательные платежи) и порог развития (плюс резервы, отпуск, обучение). Рядом живёт операционный рычаг $\text{DOL} = CM_{\text{общ}} / (CM_{\text{общ}} - F)$ — во сколько раз сильнее изменится прибыль при изменении выручки на процент: высокие постоянные затраты дают быстрый рост на подъёме и обвал на спаде, а одиночка с ноутбуком — существо с крошечным рычагом, и это преимущество перед студией с офисом.

Полезнее самого порога его чувствительность: сдвиньте по очереди цену, переменные и постоянные затраты на десять процентов и сравните новые пороги. Результат почти всегда неожидан — цена двигает порог сильнее, чем затраты, потому что входит и в маржу, и в маржинальность; работа над ценой даёт больше, чем экономия на инструментах. Вторая тонкость: при нескольких типах юнитов взвешенная маржинальность $\bar{m} = \sum_i w_i \cdot m_i$ (где $w_i$ — доли типов в выручке) меняется без изменения ваших цен и затрат, достаточно сдвига в составе заказов: вы видите «упала маржа», ищете причину в затратах, а пришло больше дешёвых мелких работ. Считайте маржу по типам; взвешенная — итог, а не объект управления.

6. Окупаемость: три разных вопроса под одним словом

Под «окупится ли» прячутся три вопроса с разной математикой: привлечение клиента (мерим сроком окупаемости CAC, §7), вложение денег в продукт, рекламу или оборудование (простой и дисконтированный срок, NPV) и вложение вашего времени в автоматизацию.

Форма кривой — J: сначала вы тратите (пресейл, скидка новичку, первичная настройка, комиссия площадки), потом клиент возвращает вложенное, и только за нулём начинает приносить деньги; пока кривая под нулём, разрыв финансируете вы. Отсюда неприятная правда роста: быстрый рост при длинной окупаемости съедает деньги, и чем успешнее вы продаёте, тем глубже яма — так и разоряются растущие бизнесы.

"""Окупаемость вложения: простой и дисконтированный срок, NPV. Потоки — ЗАГЛУШКИ.
Ставку дисконтирования не выдумывайте: это альтернативная доходность плюс премия за риск."""
from itertools import accumulate


def payback_period(flows: list[float]) -> float | None:
    """flows[0] — вложение (отрицательное), далее потоки периодов. O(T) время и память."""
    cum = list(accumulate(flows))
    for t, value in enumerate(cum):
        if value >= 0:
            return 0.0 if t == 0 else t - 1 + (-cum[t - 1]) / (value - cum[t - 1])
    return None                                             # не окупается на горизонте


project = [-500_000, 90_000, 120_000, 140_000, 140_000, 140_000, 140_000]   # заглушки
r = 0.02                                                    # за период; ПОДСТАВЬТЕ СВОЮ
disc = [cf / (1 + r) ** t for t, cf in enumerate(project)]  # деньги завтра дешевле, O(T)
print(f"простой {payback_period(project):.2f} | дисконтированный {payback_period(disc):.2f} "
      f"| NPV {sum(disc):,.0f}")

Чего не говорит простой срок окупаемости. Он игнорирует всё, что происходит после точки окупаемости (проект с коротким сроком и мёртвым хвостом выглядит лучше долгоиграющего), не учитывает стоимость денег во времени и ничего не знает о риске: им удобно отсекать плохое, но нельзя выбирать лучшее. Корректнее NPV — но у него своя ловушка, ставка дисконтирования: её смысл — доходность вашей лучшей альтернативы плюс премия за риск этой затеи, а для инженера альтернатива часто просто «те же часы, проданные текущим клиентам». Окупаемость автоматизации — любимая ловушка: формула $T_{\text{окуп}} = H_{\text{вложено}} / H_{\text{экономия}}$ требует трёх поправок, превращающих «окупится за полгода» в «никогда»: сопровождение, вероятность, что задача исчезнет и ваша же ошибка оценки (Оценка и границы работ). И честно спросите себя, не в том ли причина, что писать скрипт приятнее, чем делать скучное руками.

7. CAC, LTV и почему их отношение так часто врёт

CAC (customer acquisition cost) — сколько стоит привести одного платящего клиента: все затраты на привлечение за период, делённые на число новых клиентов. Для фрилансера это часы пресейла (включая проигранные сделки), время на контент и выступления, комиссии площадок, скидки новичкам, бесплатные диагностики — прежде всего время по вменённой себестоимости: инженер, который «ничего не тратит на маркетинг», обычно тратит на него треть рабочего года. LTV (lifetime value) — сколько маржинальной прибыли (не выручки!) принесёт клиент за всё время жизни: при постоянной вероятности оттока $c$ за период сумма геометрического ряда даёт хрестоматийное $LTV = ARPU \cdot m / c$. Формула красивая и почти всегда врёт; честнее — ограниченный горизонт $T$ и дисконтирование:

$$LTV_T = \frac{ARPU \cdot m}{c}\bigl(1 - (1 - c)^{T}\bigr), \qquad LTV_T^{d} = \sum_{t=1}^{T} \frac{ARPU \cdot m \cdot (1 - c)^{t-1}}{(1 + d)^{t}}$$

Бесконечная формула предполагает постоянный отток (а он почти никогда не постоянен: в первые периоды уходят чаще), однородность клиентов (а у вас есть и трёхмесячные, и трёхлетние) и не дисконтирует. При маленьком $c$ результат улетает в небо, и на эти воображаемые деньги начинают тратить настоящие. Для того, у кого нет запаса, срок окупаемости привлечения $T_{CAC} = CAC / (ARPU \cdot m)$ важнее отношения LTV/CAC: он задаёт, сколько клиентов можно привлекать одновременно, не убившись кассовым разрывом. Правило «LTV втрое больше CAC» — венчурная эвристика: она молчит о сроке, о вашей подушке и о том, что LTV — прогноз, а CAC — уже потраченные деньги.

"""LTV с конечным горизонтом и дисконтом, окупаемость CAC. Значения — ЗАГЛУШКИ. O(T)."""


def ltv(arpu, margin, churn, horizon: int, discount: float = 0.0) -> float:
    return sum(arpu * margin * (1 - churn) ** (t - 1) / (1 + discount) ** t
               for t in range(1, horizon + 1))

arpu, margin, churn, cac = 4_000, 0.70, 0.06, 22_000
print(f"окупаемость CAC: {cac / (arpu * margin):.1f} периодов")
for horizon in (6, 12, 24, 60):
    v = ltv(arpu, margin, churn, horizon, discount=0.015)
    print(f"горизонт {horizon:>2}: LTV {v:>9,.0f} | LTV/CAC {v / cac:>4.1f}")
print(f"бесконечный горизонт (осторожно): {arpu * margin / churn:,.0f}")

Запустите — и увидите главное: LTV/CAC почти целиком определяется выбранным горизонтом. «3x» на пяти годах и «3x» на годе — разные бизнесы; всегда пишите горизонт рядом с числом, иначе это не метрика, а мнение. Полезное упражнение — разложить направления по двум осям, маржинальность и скорость возврата денег: высокая маржа с быстрой окупаемостью — ядро, его защищают и повторяют; высокая маржа с долгой окупаемостью терпима, пока хватает подушки; низкая маржа с быстрым возвратом — оборот ради оборота; низкая маржа с долгой окупаемостью — кандидат на отказ или новую цену. Типичная находка: любимое направление сидит в последнем квадранте, а платит за жизнь скучное из первого.

8. Средние убивают: считайте по когортам и разрезам

Самая частая аналитическая ошибка — одно среднее по всему: оно скрывает ровно то, ради чего вы считали, — какая часть дела зарабатывает, а какая проедает. Условный пример (числа-заглушки):

Средняя маржа положительна, «бизнес в плюсе». Но биржа убыточна и даёт три четверти клиентов, то есть съедает три четверти вашего времени, а рост «в целом» означает рост убыточной части — эффект агрегирования, родственник парадокса Симпсона. Решение не «поднажать», а прекратить, поднять цену или переделать канал. Минимальные разрезы: канал, тип работы, сегмент, когорта по месяцу первой сделки — только когорты показывают, становится ли новый бизнес лучше старого.

-- Маржа и скорость денег по клиентам и каналам. PostgreSQL.
-- :hour_cost — ваша вменённая себестоимость часа, передаётся параметром.
WITH cost AS (               -- часы и прямые затраты по сделке; транзит исключаем
    SELECT d.id, d.client_id, d.started_at, COALESCE(SUM(t.hours), 0) AS hours,
           COALESCE(SUM(e.amount), 0) AS expense
    FROM deal d
    LEFT JOIN time_entry t ON t.deal_id = d.id
    LEFT JOIN expense    e ON e.deal_id = d.id AND NOT e.pass_through
    GROUP BY d.id
), money AS (                -- реально полученные деньги за вычетом комиссий
    SELECT i.deal_id, SUM(p.amount - p.fee) AS received, MIN(p.paid_at) AS first_paid
    FROM invoice i JOIN payment p ON p.invoice_id = i.id AND NOT p.refunded
    GROUP BY i.deal_id
)
SELECT c.channel, c.name AS client,
       date_trunc('month', MIN(k.started_at))::date         AS cohort_month,
       SUM(m.received - k.expense - k.hours * :hour_cost)   AS contribution,
       ROUND(SUM(m.received) / NULLIF(SUM(k.hours), 0), 0)  AS effective_rate,
       MAX(m.first_paid - k.started_at)                     AS days_to_money
FROM cost k
JOIN client c ON c.id = k.client_id
LEFT JOIN money m ON m.deal_id = k.id
GROUP BY c.channel, c.name
ORDER BY contribution;       -- убыточные сверху: с ними и работать

Сортировка по возрастанию не кокетство: список, начинающийся с самых убыточных клиентов, — самый полезный отчёт в вашем деле, и именно его хочется не открывать. Колонка days_to_money не менее важна маржи: клиент с хорошей маржой и оплатой через сто дней — ваш кредит чужому бизнесу.

9. Минимальная система учёта, которую реально ведут

Модель без данных — фантазия, а данные не появятся, если сбор требует героизма. Работающий минимум такой:

Три поля делают всю работу: TIME_ENTRY.category (без неё не узнать, сколько стоит пресейл и правки), EXPENSE.pass_through (отделяет ваш оборот от чужих денег) и CLIENT.first_deal_at (единственный способ построить когорты задним числом). Привычка — пятнадцать минут в неделю на часы, поступления и расходы плюс час в квартал на пересчёт маржи по клиентам и каналам и ровно одно решение по итогам. Инструмент вторичен: таблица работает, а сложная система, заброшенная через месяц, нет. Конкретика по счетам, документам и отчётности — к бухгалтеру и на ФНС.

10. Услуги и продукт: одна арифметика, разные ловушки

Три места, где утекают деньги, видны прямо на схеме: привлечение тратится даже на сделки, не дошедшие до поставки; петля правок съедает маржу уже после согласования цены; между приёмкой и оплатой живёт кассовый разрыв.

Ключевая разница — в порядке появления денег. В услугах вы сначала договариваетесь, потом работаете, и худший исход — не заплатили за сделанное; в продукте сначала строите, потом выясняете, покупают ли, и худший исход — построили ненужное. Поэтому экономика продукта на ранней стадии почти вся состоит из допущений, и главный навык — не считать точнее, а удешевлять проверку допущений (Свой продукт). Продуктизированная услуга — промежуточная форма: одинаковая поставка с фиксированной ценой и известным составом работ (аудит, миграция, настройка по чек-листу), где затраты предсказуемы, пресейл короче, а маржа считается до сделки. Часто это самый быстрый способ починить юнит-экономику, не уходя в двухлетнюю стройку.

11. Решения, разбросы и риски

Модель нужна не для отчёта, а для конечного набора действий:

Точечная модель («маржа 34 процента») даёт ложную уверенность. Полезнее диапазон: прогоните сделку в трёх сценариях по двум параметрам, которые реально гуляют, — часы и доля правок сверх границ, — и смотрите не на среднее, а на долю убыточных исходов; обычно она выше, чем ощущается, и это и есть список задач — не «считать точнее», а сузить разброс (Оценка и границы работ, Вероятность и статистика).

Хорошая модель не спасает от того, что живёт вне модели. Честный список рисков:

• Прибыльный и мёртвый. Прибыль по начислению не равна деньгам на счёте: бизнес умирает от кассового разрыва, а не от отрицательной маржи — держите отдельно экономику и календарь платежей.
• Нестабильность потока. У модели нет параметра «месяц без заказов»: порог считается на год, а не на удачный месяц.
• Неплатежи. Ожидаемую потерю $q \cdot p$ закладывайте в затраты заранее; защита — предоплата, этапы, акты, переход прав после оплаты (Договоры, Работа с заказчиком).
• Выгорание как незаписанная статья затрат. Утилизация под сто процентов физически неисполнима, а износ не виден в отчёте до полной остановки — Выгорание.
• Валюта и трансграничные расчёты. Курс, комиссии и применимые правила меняют экономику сделки сильнее вашей наценки; это к бухгалтеру и банку, а не в расчёт по статье.
• Обязательства, всплывающие позже — гарантия, ответственность по договору, обязанности за прошедшие периоды: юнит, который вы считаете закрытым, может оказаться открытым. Не тратьте деньги, у которых есть шанс стать чужими.

Отдельно — стратегические сделки: убыточный проект ради кейса или входа в отрасль рационален, если решение принято осознанно и заранее ограничено бюджетом («не более N часов и один такой проект в квартал»). Стратегическая сделка без бюджета — просто убыточная сделка с красивым названием.

Мини-итог

1. Выберите юнит — повторяемый, измеримый, оплачиваемый; разные модели работы — разные юниты.
2. Считайте нетто-выручку, а не оборот: без скидок, комиссий, возвратов и транзитных сумм; ваше время — переменные затраты, а не «бесплатное».
3. $CM = p - v$ — главное число: отрицательное значит «прекратить», а не «нарастить объём».
4. $Q_{\text{бу}} = F / CM$ считается с вашим личным окладом внутри $F$; рядом держите запас прочности.
5. Пресейл и проигранные сделки относите на выигранный проект — это ваш CAC, а не «накладные расходы».
6. Горизонт обязателен рядом с LTV; срок окупаемости CAC для одиночки важнее отношения LTV/CAC.
7. Разрезы важнее средних: канал, тип, сегмент, когорта — иначе прибыльное дотирует убыточное.
8. Прибыль не равна деньгам: экономика по начислению, выживание по кассе, два отдельных отчёта.
9. Цифры про налоги и право — не из статей: параметр от бухгалтера, проверка на официальных источниках на дату, формулировки договора — у юриста.

Источники

• David Skok, SaaS Metrics 2.0 — CAC, LTV и окупаемость привлечения: forentrepreneurs.com/saas-metrics-2 · a16z, 16 Startup Metrics: a16z.com/16-startup-metrics
• Paul Graham, Default Alive or Default Dead? — короткий тест на безубыточность: paulgraham.com/aord.html · Jason Cohen, Designing the Ideal Bootstrapped Business: longform.asmartbear.com
• Ash Maurya, Running Lean (O’Reilly) — бизнес как набор проверяемых допущений: oreilly.com · Josh Kaufman, The Personal MBA: personalmba.com · определения терминов: contribution margin, break-even point
• Официальные источники по налогам и формам деятельности — только эти и на дату: ФНС, Госуслуги, pravo.gov.ru
• Смежное на портале: Метрики продукта, Ценообразование и рост, Аналитика и решения, Управление рисками

Что дальше

Юнит-экономика показывает, какая сделка выгодна и сколько таких сделок нужно, но принимает поток обращений как данность — а его надо откуда-то брать, и дешевле, чем он приносит. Следующая статья — о том, как инженеру находить клиентов без маркетолога и бюджета.

Продвижение без маркетолога: контент, комьюнити, репутация, продажи