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

Это как обещание себе "начну бегать с понедельника" — звучит приятно, но заканчивается одинаково.
Спойлер: почти никто не переписывает.
Хочу рассказать историю, почему так происходит и чем заканчивается.

История стартапа, который "успеет переписать"

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

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

И на первом созвоне я услышал знакомое:

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

Звучит разумно, правда? Убедительно.
Запускаем быстрее -> тестируем гипотезу -> получаем инвестиции -> строим всё по уму.

Я попробовал тогда оспорить, но это был разговор со стеной... убеждать бесполезно, пока боль не случилась.

Первая победа (и начало проблем)

Через два месяца продукт запустили. Да, на соплях.
Стек: то, что было под рукой, архитектура — "лишь бы работало".

И как обычно, дуракам и пьяницам... Короче, они выстрелили.
Первые клиенты пришли, инвесторы довольны, цифры растут.
Команда в эйфории.

И вот тут должна была прозвучать фраза:

Окей, ребята, пора переписать.

Но вместо этого я услышал:

Нужны новые фичи.
Конкуренты сделали интеграцию с X — нам тоже надо.

И понеслось!

Как код превращается в мину замедленного действия

Через полгода я снова заглянул в проект.
Кодовая база выросла в 5 раз.
Автотестов — ноль.
CI/CD? - зачем, Валера филигранно катит с ноута руками.
Документация? - тоже у Валерки в голове.

В багтрекере висело 100-200+ тикетов.
Скорость фичей падала, баги множились, релизы стали стрессом.

И самое интересное — команда уже не могла переписать продукт.
Причины просты:

• Цена переписывания выросла в десятки раз. У них тысячи пользователей, десятки интеграций, SLA.

• Нет времени, рынок давит, конкуренты не ждут, инвесторы требуют роста.

• Нет смелости или понятных аргументов. Как объяснить инвестору: "Мы остановим разработку на 4 месяца, чтобы сделать то же самое, но правильно"?

Они пытались тянуть на старой базе ещё год.
А потом начали терять клиентов.
Каждая новая фича занимала в 3 раза больше времени, чем планировалось. Баги в проде стали нормой.
Финал предсказуем: проект просто слили за копейки.

Почему "потом перепишем" — миф

Вот три причины, почему переписывание почти не случается:

1. Рост пожирает ресурсы
   Каждый день появляются новые фичи, баги, клиенты, партнёры. В этой гонке "переписать" всегда внизу приоритетов.

2. Цена растёт экспоненциально
   В первый месяц переписать код можно за неделю. Через год — за полгода (и то, неуверенно).

3. Психология бизнеса
   Фраза "мы заморозим развитие ради переписывания" убивает переговоры с инвесторами или начальством.

Почему MVP != "сделать на коленке"

Сразу уточню: я не против MVP.
Я против хаоса под видом MVP.
Проблема не в том, что вы делаете быстро, а в том, что вы делаете без понимания, как это будет жить завтра.

Есть разница между:

• MVP, спроектированным так, чтобы выдержать 2–3 итерации роста

• и MVP на соплях, который развалится при первой нагрузке

Первое — гибкость.
Второе — технический долг, который сожрёт вас.

Что делать вместо "потом перепишем"

1. Думайте наперёд, но без фанатизма

Вам не нужен монолит размером с Enterprise, но и «файл на 10 000 строк» — плохая идея.
Сделайте архитектуру такой, чтобы её можно было расширять без боли.
Представьте, что вы Шерлок Холмс: предугадываете пару ходов вперёд, а не строите план на 10 лет.

2. Инфраструктура — не роскошь

Автотесты, CI/CD, нормальное логирование.
Не для красоты, а чтобы завтра не ловить баги в проде в три часа ночи.
Запомните простую математику: час на тесты сегодня = неделя экономии завтра.

3. Технический долг — это кредит под дикий процент

Его нельзя игнорировать.
Договоритесь в команде: как только долг выходит за лимит — ставим фичи на паузу, идём чистить.
Неприятно? Да!
Но дешевле, чем потом переписывать всё с нуля или терять продукт.

Итог

Фраза "мы потом перепишем" звучит безобидно.
Но в реальности это ловушка, из которой почти никто не выбирается.

Если вы слышите её на мите — задайте три вопроса:

• Когда именно?

• Кто это сделает?

• За чей счёт?

Если честного ответа нет — поздравляю, вы строите небоскрёб на песке.

Оффтоп

В Telegram-канале Техдир на пальцах я также разбираю подобные проблемы/кейсы/советы. Там все про разработку и управление, но простым языком, понятным бизнесу.