Как потерять деньги в стартапе, который уже получает оплаты

«Если у стартапа уже есть оплаты, почему ему всё ещё может не хватать денег?» Я считаю вопрос точным. Оплата говорит, что клиент расстался с деньгами, но не рассказывает, когда компания сможет ими распорядиться и сколько ресурсов потребуется, чтобы выполнить обещание. Diaverse получает оплаты не первый год — их уже больше 35 000, — и я сам видел, что продажи не защищают от тяжёлой структуры расходов.

Оплата только запускает движение денег

После оплаты сумма проходит через платёжный канал. Посредник может удержать комиссию, перечислить остаток позднее или объединить операции в выплату. Клиент уже заплатил, но вся сумма ещё не доступна компании. Даже когда деньги поступили, часть может относиться к обязательству перед покупателем или к расходам, которые уже возникли.

Я бы попросил основателя рассказать одну такую цепочку от начала до конца. Когда покупатель оплатил, что удержал посредник и какой датой компания увидела остаток? Мне также важно понять, что ещё нужно выполнить по сделке и когда наступит следующее обязательство. Эти вопросы звучат просто, но помогают увидеть кассовый разрыв раньше, чем он превратится в экстренный поиск денег.

Что я увидел в Diaverse

В посте от 8 октября я рассказывал о прежней структуре Diaverse, которая существовала полутора годами раньше: разработчики, дизайнеры, менеджеры, проджекты, поддержка, отделы, согласования и отчёты. Денег уходило много, а двигались мы медленнее, чем хотелось. Разбирая расходы, я увидел, что значительная часть ресурсов шла на обслуживание самой системы, а некоторые функции создавались до проверки, нужны ли они людям. После этого мы перестроили разработку: примерно тот же объём работы стал обходиться дешевле, а обновления выходили быстрее.

Признать это было неприятно. Когда процессы уже сложились, каждый следующий расход легко объяснить необходимостью. Но я стал спрашивать себя, помогает ли работа людям пользоваться продуктом или система расходует силы на саму себя.

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

На каком этапе расход превращается в пользу

Я не считаю, что любой расход нужно сокращать. Оплата покупателя обычно предполагает работу: поддержать приложение, исправить ошибку, выполнить заказ, разобраться с обращением. Вопрос для меня не в том, можно ли обойтись совсем без расходов. Я смотрю, какие расходы необходимы для обещания клиенту и какие появились до того, как стало ясно, что они нужны. Например, платёж поставщику может быть обязательным для запуска, а дополнительная функция — пока только предположением о том, что пригодится пользователю. Это разные основания для траты, даже если обе строки стоят рядом в бюджете.

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

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

Такая проверка оставляет место долгой работе над продуктом и не заставляет команду гнаться за краткосрочной цифрой. Иногда продукту нужно время, чтобы стать проще или надёжнее. Для меня важно другое: видеть, что команда знает, какой именно результат она пытается получить, и не продолжает финансировать функцию лишь потому, что на неё уже потрачены силы.

Если расход долгосрочный, я хочу понимать его ближайший проверяемый этап. Большой проект может состоять из нескольких решений: сначала проверить потребность, затем вложиться в разработку, после — поддерживать уже используемую функцию. Поэтапный взгляд помогает увидеть момент, когда новые траты опережают то, что компания узнала о пользователях.

Условный пример: деньги приходят позже расходов

Условный пример, не показатели Diaverse. День 1: клиент платит 1 000 ₽ за месяц услуги. В тот же день компания должна перечислить поставщику 250 ₽, но посредник отправит выплату только на день 7 и удержит 100 ₽. Значит, 250 ₽ поставщику нужны на первой неделе, а 900 ₽ придут только на день 7. Если свободного остатка нет, компании понадобится найти эти 250 ₽ раньше выплаты посредника.

В течение месяца на исполнение услуги уйдёт ещё 300 ₽. К концу месяца расчёт такой: 1 000 ₽ − 100 ₽ удержания − 250 ₽ поставщику − 300 ₽ на исполнение = 350 ₽. Этот остаток не отменяет кассовый разрыв первой недели: дату обязательного платежа нельзя закрыть деньгами, которые придут позже. Если у компании нет начального резерва, она должна покрыть ранний платёж из другого источника или договориться о сроке с поставщиком. Это только кассовый расчёт: он не определяет бухгалтерскую выручку и не учитывает налоги. Я считаю 350 ₽ остатком по перечисленным тратам; другие расходы в этом условном примере не заложены.

Удержания, сроки и обязательства

IFRS 15 связывает признание выручки с передачей обещанной услуги или товара. В нём также описаны договорный актив и договорное обязательство для случаев, когда выполнение и оплата не совпадают по времени. Поэтому платёж, признанная выручка и исполненное обязательство могут приходиться на разные даты.

Путь клиента к деньгам компании зависит от канала оплаты. Магазин приложений, банк или платёжный посредник могут применять разные комиссии и сроки. Если стартап работает в нескольких странах, условия могут отличаться по валюте и датам расчёта. Я не складываю такие выплаты в одну условную дату: задержка одного канала может совпасть с платежом, который нельзя отложить.

Для каждого канала мне важно увидеть сумму оплат за период, возвраты, удержания и дату фактической выплаты, затем сопоставить её с банковским поступлением. Отдельные строки не обязаны совпадать по дате, если отчёт площадки считает покупку, а выписка фиксирует перечисление средств. Важно объяснить переход от одной суммы к другой и увидеть, когда деньги окажутся в распоряжении компании.

Затем я посмотрел бы на выплаты по календарю. Зарплаты, налоги, счета подрядчиков, аренда и возвраты приходят по своим датам. В британском руководстве по финансовым моделям также рекомендуют проверять последствия задержек и отклонений от плана: такая проверка помогает заранее увидеть недели, где обязательства наступают раньше поступлений.

Договорное обязательство остаётся значимым, пока компания не выполнила обещанную работу. Поэтому я отдельно смотрю на сумму, которую можно потратить сегодня, и на сумму, за которой уже стоит предстоящая услуга.

Компания может быть прибыльной в отчёте за месяц и испытывать нехватку средств в конкретную неделю, если поступления задержались, а обязательные платежи совпали.

Полезно проверить, что будет при росте продаж. Рост может увеличить нагрузку на поддержку, потребовать дополнительных мощностей, лицензий или людей для выполнения заказа. Значит, рост операций способен увеличить и расходы на исполнение обещаний покупателям. Эти расходы не обязательно плохие. Они становятся проблемой, если в модели растут оплаты, но не появляются ресурсы для исполнения и даты выплат.

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

Мой опыт перестройки Diaverse напоминает мне, как расходы могут продолжаться по инерции. Ответы о календаре покажут, насколько внимательно компания управляет обязательствами перед покупателями и поставщиками. Для меня разговор не сводится к одной «правильной» сумме на счёте. Я хочу видеть, что основатель понимает последовательность платежей и может объяснить, почему доступный остаток отличается от суммы продаж. Так я понимаю, управляет ли он ликвидностью или читает только итоговый показатель за месяц.

Что означают оплаты Diaverse

У Diaverse более 35 000 оплат и $1,5 млн оборота за несколько лет. Операционная прибыльность — отдельный факт о компании, а оборот не равен прибыли. Эти цифры не заменяют понимания графика поступлений и обязательств. Я не считаю, что одна сильная сумма должна отвечать на вопрос о каждом кассовом решении.

Первый внешний раунд Diaverse — $300K; его цель — ускорить развитие продукта и международное масштабирование. После раунда мне важно направлять деньги на работу, которая двигает продукт к людям и помогает проверить новые рынки. Оплата клиента сама по себе не доказывает, что следующий расход нужен, а раунд не отменяет обязательств перед покупателями. Поэтому в любом бюджете я смотрю, что именно получит пользователь и когда это станет видно.

Я хочу, чтобы игра помогла большему числу людей выходить гулять и однажды приблизила нас к цели: миллиард человек ежедневно проходит 10 000 шагов. Для меня важно, чтобы каждый рубль раунда приближал продукт к людям — через конкретную работу над игрой и её выходом на новые рынки.

Оставьте заявку в листе ожидания — на встрече разберём условия раунда и ваши вопросы.