4 ошибки на $40k маржи в моей студии мобильной разработки. И одно решение, которое всё окупило

Мы — студия из трёх человек, делаем мобильные приложения для B2B-клиентов. Третий год. MRR — $18k. До этого я шесть лет работал in-house программистом, и думал, что про разработку знаю достаточно, чтобы открыть свою студию без сюрпризов.
Сюрпризов было много. Эта статья — не про успех, а про четыре решения, которые я принял неправильно за 2,5 года, и которые в сумме обошлись бизнесу примерно в $40-50k недополученной маржи. И про одно решение, которое в итоге окупило все остальные.
Пишу для тех, кто запускает свою маленькую студию или думает запустить. Если узнаете себя хотя бы в одной из ошибок — сэкономите больше, чем стоит подписка на vc.ru.

Первые 8 месяцев я работал на почасовой. Ставил себе $50/час, считал часы, отправлял отчёты раз в неделю, выставлял счёт в конце месяца. Это казалось «честно»: клиент видит, за что платит, я работаю столько, сколько работаю.
Проблема почасовой схемы на разработке проста: гипотеза в 3 часа становится 8 часами. И не потому, что разработчик ленится — а потому, что задачи в мобильной разработке нелинейные. Один CocoaPods-конфликт, одна замороченная интеграция с банковским API клиента — и оценка летит в два раза.
В этой схеме у меня было два варианта:
1. Выставлять реальное время и слышать «а почему так много?»
2. Подгонять часы под оценку и тихо терять маржу.
Я делал и то, и другое в разных проектах. В первом случае терял доверие клиента. Во втором — деньги.
Перешёл на фиксированную цену на 9-м месяце. Стало хуже на старте — пришлось научиться нормально оценивать (читай: систематически закладывать запас 30-40%). Но через 3-4 месяца маржа поднялась с ~25% до ~45-50%. И, что неожиданно — клиенты стали относиться к проектам серьёзнее: раз заранее заплатил $25k, начинает реально думать, какие фичи ему действительно нужны.
Урок: на разработке почасовая работает только для очень разовых задач или для очень опытного клиента, который сам понимает, что час — это не «1 час кодинга», а час с контекст-свитчингом, ревью, дебаггингом и созвоном. Все остальные кейсы — фикс.

Я брал всё, что несли. MVP для B2C-стартапа? Бери. Внутренний инструмент для отдела продаж компании из 50 человек? Бери. Рефакторинг легаси-приложения на старом Objective-C? Бери, что-нибудь придумаем.
Каждый из этих проектов был мини-MBA в отдельной индустрии. Каждый стек был немного другой. Каждый клиент общался по-своему. И за каждое такое «возьму, разберусь» я платил в среднем 30-40% времени, которое уходило на разбираться, а не делать.
Перелом случился на проекте с одной фитнес-платформой. B2C-приложение, нужно было сделать сложную интеграцию с health-данными iOS. Это был мой первый проект в healthcare, я недооценил complexity в 2,5 раза. Закрыл с маржей ~5% и нервотрёпкой на месяц вперёд.
После этого я сел и посмотрел на P&L по типам проектов за 12 месяцев. Картина была неприятной:
- B2B internal tools: средняя маржа 47%
- Кастомные B2C-приложения: средняя маржа 18%
- Рефакторинг чужих кодовых баз: средняя маржа 11%
- MVP для стартапов: средняя маржа 23%, плюс две истории, где клиент не доплатил последний транш
С 14-го месяца я начал говорить «нет» всему, что не B2B internal tools или B2B-приложения для конечных клиентов корпоративного клиента. Темпы роста замедлились на 3-4 месяца — пайплайн перестроился. Но после этого выручка на проект выросла, маржа стабилизировалась около 45%, а количество «душных» проектов упало почти до нуля.
Урок: ниша даёт не только маркетинговый фокус, но и операционную маржу. Каждая «случайная» сделка вне ниши — это скрытый налог на R&D-время команды.

На 14-м месяце у меня был пайплайн из трёх клиентов и постоянное ощущение, что я задыхаюсь в одиночку. Нанял Senior React Native-разработчика на $4k/мес. Подписал ему фуллтайм-контракт, не сделав никакого buffer-плана на случай сжатия.
Через 3 месяца самый крупный клиент решил поставить проект на паузу — у них поменялся стек технологий на внутреннем уровне. MRR упал с $11k до $7k. Дев — на полной зарплате. Накопленных средств на 2 месяца.
Я в итоге выкрутился: за следующие 4 месяца взял подряд 3 контракта подряд через старые контакты, часть из которых я брал бы только в крайнем случае (см. Ошибку №2). Плюс начал брать выходные клиенты — что серьёзно ударило по личной жизни.
После этой истории я ввёл для себя правило: нанимать только когда backlog проектов покрывает 130%+ текущей загрузки команды в течение 2+ месяцев подряд. Не «может покрыть». А реально покрывает в моменте. Один большой ушедший клиент не должен пробивать дыру в P&L.
Второго разработчика после этого нанял ещё через 9 месяцев — уже на правильных условиях.
Урок: в маленькой студии cash flow важнее темпов роста. Один «лишний» зарплатный наём за полгода до того, как ты его реально потянешь — это не «инвестиция в команду», это поход в банк с твоими собственными деньгами.

Первые пять контрактов я делал с принципом «договоримся по ходу». В контракте было прописано общее описание проекта на полстраницы, бюджет, deadline. Список фич — нет. Сценарии использования — нет. Что считается out-of-scope — нет.
Что происходило: на середине каждого проекта появлялись «маленькие добавки». «А давайте ещё push-нотификации сделаем». «А можно тут небольшую админку добавить?». «А давайте формы переделаем, мы перетестировали с пользователями». Каждая «маленькая добавка» съедала 2-5 дней работы. Эти дни в контракте не были учтены.
В итоге фактическая часовая ставка на этих контрактах падала до $25-30/час вместо заложенных $80. Маржа испарялась. Один проект мы закрыли в убыток на ~$8k на бюджете $30k — просто из-за того, что я не научился говорить «это change request, давайте отдельно оценим».
После того проекта я сел и сделал шаблон контракта в Notion: фиксированный список фич, явный список «не входит в проект», политика change requests (отдельная смета, минимальный счёт $500), правила приёмки. Это — самая важная неинженерная страница в нашем бизнесе сейчас.
Маржа на проектах после введения шаблона выросла на 12-15 процентных пунктов. Не потому, что цена стала выше. А потому, что бесплатной работы стало нет.
Урок: клиенту нравится «мы сделаем как надо» — но он же первый будет недоволен, когда «как надо» окажется в два раза дороже его внутреннего ожидания. Жёсткий скоуп защищает обе стороны.

На фоне всех этих граблей я в какой-то момент устал от двух вещей. Первое — от ежедневных созвонов с командой, где половина времени уходила на «а что ты сейчас делаешь» и «где мы стоим по сроку». Второе — от клиентских писем «А когда будет вот эта фича?» и «Можно показать, как сейчас выглядит экран?».
Перевёл студию на async-first процесс. Конкретно:
- Никаких ежедневных созвонов. Любой апдейт — текстом, в Notion, с тегом дня.
- Один еженедельный синк в команде, на час, по чёткой повестке.
- Каждый проект имеет страницу в Notion: roadmap по неделям, текущий sprint, лог изменений, открытые вопросы, deliverables, документация принятых решений.
- Каждому клиенту даём доступ к этой странице. Read-only, но реальный.
Эффект оказался намного больше, чем я ожидал.
Внутри команды:
- Стали реально работать в разных часовых поясах (один из ребят живёт на 4 часа восточнее). До этого мы теряли по сути полдня каждый из-за созвонов.
- Меньше «менеджмента» — больше работы. Я считал свой менеджерский overhead — упал с ~30% рабочего времени до ~12%.
- Решения стали приниматься в текстовой форме, с обоснованием. Это автоматически даёт нам базу знаний, которая раньше жила в чьей-то голове.
С клиентами:
- Количество писем «где мы по сроку» упало в 4-5 раз. Клиент сам открывает Notion-страницу и смотрит.
- Возникающие вопросы стали более содержательными — клиенты задают вопросы по конкретным task'ам, потому что видят их.
- И — самое неожиданное — Notion-страница стала инструментом продаж. На последних 6 контрактах из 8 я показывал прототип клиентского Notion-пространства до подписания. Клиенты прямо говорили, что «это уровень процесса, какой мы у конкурентов не видели». Конверсия предложения в подписанный контракт у меня поднялась с ~35% до ~70%. На том же самом ценнике.
Это и есть та одна вещь, которая окупила все четыре ошибки. Не «использование Notion». А формализация процесса в видимом для всех формате. Notion — просто инструмент. Можно было бы сделать на Linear, на Coda, на Google Docs. Главное — что для команды и клиента стало одинаково видимо, как мы работаем.

Сейчас мы на $18k MRR, маржа стабильно 45-50%, очередь на 2 месяца вперёд. Не «успешный успех» — скорее «спокойный устоявшийся бизнес». Но если бы 2 года назад я знал про эти четыре грабли, я бы выбрался к тем же $18k MRR раньше на 8-10 месяцев и с гораздо меньшим количеством бессонных ночей.
В следующих постах планирую разобрать пару вещей, которые делаю параллельно с основным бизнесом — в том числе свой подход к ведению личных проектов и трекингу решений за пределами кода. Если есть тема, про которую хочется почитать в формате «как у маленькой студии» — пишите в комментариях.
---
Если статья откликнулась — буду рад дискуссии в комментариях. Особенно интересно: какие ошибки за первые годы маленькой студии оказались самыми дорогими у вас?