Технический долг в mvp — тема, которая определяет успех IT-проекта. Восемь месяцев после запуска MVP. Стартап привлёк первых пользователей, есть деньги от инвесторов, команда готова масштабироваться. И тут новый CTO смотрит в код и говорит три слова, которых боится каждый основатель: «Надо переписать всё».
Это происходит чаще, чем кажется. Не потому что разработчики плохие. А потому что MVP, написанный «быстро и чтобы работало», через год превращается в продукт, который невозможно развивать без полной переработки.
Технический долг — это не абстракция. Это реальные деньги (переписывание с нуля стоит от 2 до 5 миллионов рублей), реальное время (6-12 месяцев) и реальный риск потерять рынок пока конкурент не стоит на месте.
Но вот что контринтуитивно: не весь технический долг одинаково опасен. Есть долг, который нормален для стартапа. И есть долг, который убивает компании. Разберёмся, как их отличить.
Что такое технический долг — объяснение для нетехнического основателя
Рассмотрим, как технический долг в mvp работает на практике.
Технический долг — это метафора, которую ввёл программист Уорд Каннингем ещё в 1992 году. Смысл простой: когда вы принимаете технические решения ради скорости сейчас, вы берёте «кредит». Позже придётся платить «проценты» — время и деньги на исправление этих решений.
Как и в финансах, не всякий долг — плохой. Ипотека — это долг, но он позволяет жить в квартире прямо сейчас. Потребительский кредит под 30% на телефор — это другая история.
В разработке то же самое. Сознательный компромисс ради скорости — нормально. Непродуманная архитектура по незнанию — катастрофа.
Два типа технического долга
Вопрос технический долг в mvp заслуживает детального анализа.
Стратегический долг — нормально и даже нужно
Это сознательные компромиссы, которые вы принимаете, зная об их последствиях, потому что скорость важнее идеальности на этом этапе.
Примеры стратегического долга в MVP:
- Hardcoded конфиги — email-шаблоны прямо в коде, не в CMS. Некрасиво, но работает.
- Manual processes — операции, которые пока делаются руками (onboarding, верификация), вместо автоматизации.
- Нет i18n — интерфейс только на русском, без поддержки локализации. Для стартапа на российском рынке это нормально на первый год.
- Упрощённый мониторинг — Sentry для ошибок и UptimeRobot вместо полноценного Datadog.
- Нет кеширования везде — кешируется только самое критичное, остальное пока работает медленнее.
Ключевое отличие стратегического долга: вы знаете, что он есть, и знаете, когда его закроете. После product-market fit, после раунда, после роста до N тысяч пользователей — конкретный триггер.
Случайный долг — убивает стартапы
Это непродуманные архитектурные решения, которые возникают не из-за сознательного выбора, а из-за спешки, неопытности или халтуры подрядчика.
Признаки случайного долга:
- Один сервис делает всё — нет разделения ответственности. Авторизация, бизнес-логика, работа с базой, рассылки — всё в одном месте. Изменение одного ломает другое.
- Бизнес-логика захардкожена в SQL-запросах — сложные условия прямо в запросах к базе. Тестировать невозможно, менять опасно.
- Нет тестов вообще — каждый деплой — это риск. Разработчики боятся трогать старый код.
- Нет документации API — новый разработчик не понимает, как интегрировать модули. Время онбординга — месяц.
- Зависимости не управляются — npm audit показывает 40 уязвимостей, никто не обновляет пакеты годами.
Случайный долг не закрывается рефакторингом. Его надо переписывать. И чем дольше ждать — тем дороже.
5 красных флагов накопленного технического долга
Именно технический долг в mvp определяет результат для бизнеса.
Как основателю понять, что в продукте уже есть критичный долг — даже если вы не программист?
| Признак | Что это значит | Что будет дальше |
|---|---|---|
| Любая новая фича занимает в 3 раза дольше, чем раньше | Архитектура не позволяет расширяться | Скорость разработки будет только падать |
| Разработчики боятся трогать старый код | Нет тестов, нет документации | Критичные баги появляются в неожиданных местах |
| Новый разработчик не въезжает за 2 недели | Bus factor 1, нет документации | Потеря единственного носителя знаний = катастрофа |
| «Небольшая правка» ломает что-то ещё | Высокая связанность модулей | Каждый деплой — это риск даунтайма |
| Нет автодеплоя, деплой делается вручную | Нет CI/CD, процессы не формализованы | Деплои редкие, итерации медленные |
Сколько стоит переработка
При правильном подходе технический долг в mvp становится конкурентным преимуществом.
Это вопрос, который основатели задают слишком поздно. Вот примерная картина:
- Рефакторинг (если архитектура в принципе живая): 400-800 тысяч рублей, 2-4 месяца
- Частичная переработка (один проблемный модуль): 600 тысяч — 1,5 млн рублей, 3-5 месяцев
- Переписать с нуля (если архитектура нежизнеспособна): 1,5-5 млн рублей, 6-12 месяцев
Плюс к этому — потерянное время рыночного присутствия, стресс команды и объяснения инвесторам, почему прогресс встал.
Но самое дорогое — это упущенные возможности. Пока вы переписываете, конкурент выпускает новые фичи.
7 вопросов подрядчику, чтобы не получить «долговой» MVP
Далее — о ключевых аспектах технический долг в mvp.
Если вы только выбираете команду разработки — вот список вопросов, которые нужно задать до подписания договора. Ответы покажут, понимает ли подрядчик разницу между быстро и правильно.
1. Покрытие тестами: какой % кодовой базы покрыт unit-тестами?
Хороший ответ: «Для бизнес-логики — 60-80%, для интеграционных сценариев — ключевые пути». Плохой ответ: «Тесты пишем после». Нет тестов = нет возможности рефакторить без страха.
2. Архитектура: как разделены слои (presentation / business logic / data)?
Хороший ответ: конкретная схема с объяснением, почему именно так. Плохой ответ: «У нас FastAPI, там всё внутри». Смешение слоёв — главная причина, почему через год надо переписывать.
3. CI/CD: есть ли автоматический деплой?
Хороший ответ: GitHub Actions / GitLab CI с автотестами перед деплоем. Плохой ответ: «Деплоим руками, когда нужно». Без CI/CD деплои редкие и рискованные.
4. Документация API: есть ли OpenAPI/Swagger?
Хороший ответ: «Да, Swagger доступен по /docs, обновляется автоматически». Плохой ответ: «Договоримся с разработчиками напрямую». Без документации каждый новый разработчик тратит недели на онбординг.
5. Зависимости: как управляете версиями (Dependabot/Renovate)?
Хороший ответ: Dependabot настроен, PR на обновления приходят автоматически. Плохой ответ: «Обновляем когда нужно». Устаревшие зависимости = дыры в безопасности, особенно критично для FinTech.
6. Monitoring: какие инструменты observability используются?
Хороший ответ: Sentry для ошибок, Grafana/Prometheus для метрик, алерты в Telegram/Slack. Плохой ответ: «Узнаем о проблемах, когда пользователи напишут». Без мониторинга вы не знаете, что происходит ночью.
7. Onboarding: сколько времени займёт ввод нового разработчика?
Хороший ответ: «До самостоятельной работы — 3-5 дней, есть README с инструкциями». Плохой ответ: «Зависит от человека». Если онбординг занимает месяц — это bus factor 1, и система держится на одном человеке.
Когда переписать с нуля лучше, чем рефакторинг
Опыт показывает: технический долг в mvp требует системного подхода.
Это сложный вопрос, и правильного универсального ответа нет. Но есть признаки, при которых рефакторинг бессмысленен:
- Архитектура фундаментально неверная — например, монолит, в котором все сервисы перемешаны, и их нельзя разделить без полной переработки
- Технологический стек устарел — фреймворк больше не поддерживается, нет экспертизы на рынке
- Стоимость рефакторинга сопоставима со стоимостью переписывания, но результат хуже
- Команда, которая писала MVP, недоступна и нет документации — никто не знает, как это работает
Признаки, при которых рефакторинг лучше:
- Бизнес-логика правильная, проблема — только в организации кода
- Есть тесты, которые покрывают основные сценарии — есть за что держаться при переработке
- Команда понимает кодовую базу и может работать итеративно
- Переписывание с нуля займёт больше года — рынок не ждёт
Правило хирурга: рефакторинг — это операция на работающем сердце. Переписывание — это трансплантация. Второе только в случае крайней необходимости.
Моя позиция: хороший MVP — это MVP, который не стыдно показать следующему CTO
Мы в IT2BE часто принимаем проекты после других команд. И я заметил закономерность: плохой MVP — это не тот, который написан быстро. Плохой MVP — это тот, который написан непонятно.
Код может быть несовершенным. Он может иметь hardcoded конфиги и manual processes. Но он должен быть читаемым. Когда первый разработчик уходит, а новый не может разобраться за неделю — это не MVP, это технический долг в форме продукта.
Хороший MVP делается так, чтобы любой старший разработчик мог открыть репозиторий и понять систему за день. Не идеально — но структурированно, логично, с базовой документацией.
Это не сильно дороже. Это вопрос дисциплины и опыта команды, а не времени.
О том, как мы строим масштабируемую архитектуру с самого начала, читайте в разделе Масштабирование. А если хотите понять, как мы работаем с FinTech-стеком — загляните в раздел Разработка FinTech MVP.
Как понять, что в MVP накопился критичный тех. долг?
Главные признаки: каждая новая фича занимает в 2-3 раза дольше обычного; разработчики боятся трогать старый код и делают изменения максимально осторожно; новый человек в команде не въезжает за две недели; «небольшая правка» регулярно ломает что-то в другом месте; нет автодеплоя, деплои делаются руками и редко. Если есть три и более признака — пора на технический аудит.
Рефакторинг или переписать с нуля — как выбрать?
Рефакторинг работает, когда бизнес-логика правильная, есть хотя бы базовое покрытие тестами и команда понимает кодовую базу. Переписывание оправдано, если архитектура фундаментально неверная, стек устарел или стоимость рефакторинга сопоставима со стоимостью переписывания при худшем результате. Всегда начинайте с технического аудита — он даст точный ответ за 1-2 дня работы опытного архитектора.
Сколько стоит избавиться от технического долга?
Зависит от глубины проблемы. Рефакторинг одного модуля — от 200 до 500 тысяч рублей, 4-8 недель. Частичная переработка архитектуры — 600 тысяч — 1,5 млн рублей, 2-4 месяца. Полное переписывание MVP с нуля — от 1,5 до 4 млн рублей, 5-10 месяцев. Чем раньше заняться проблемой, тем дешевле. Долг растёт экспоненциально, а не линейно.
Как не допустить тех. долга с самого начала?
Выбирайте команду, которая явно разделяет слои приложения (presentation / business logic / data), пишет тесты на бизнес-логику, настраивает CI/CD с первого дня и документирует API автоматически через OpenAPI. Задайте семь вопросов из статьи до подписания договора. Хорошая команда ответит конкретно — и это уже сигнал о качестве будущего кода.
Если вы хотите обсудить архитектуру вашего MVP — на этапе планирования или уже имея работающий продукт — команда IT2BE готова провести технический разбор. Мы строим FinTech и EdTech MVP так, чтобы через год не нужно было переписывать. Подробнее о нашем подходе к разработке — в разделе AI для стартапов.