Когда пересобрать приложение на ИИ заново (а когда продолжать дорабатывать)

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

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

Она спросила меня: «В какой момент стоит просто начать всё заново?»

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

Почему пересобрать заново так заманчиво (даже когда это неправильно)

Когда приложение начинает тормозить, или вести себя непредсказуемо, или просто выглядит уже не так, как хочется, — инстинкт говорит выбросить его и начать с чистого листа. Чистый лист. Без всего старого балласта.

Этот инстинкт обычно неправ.

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

Большинство приложений на ИИ можно спасти доработкой. Хороший ИИ-конструктор приложений может перестроить запутанную модель данных, упростить перегруженную страницу или привести в порядок функцию, которая разрослась бесконтрольно. Важно понимать, когда вы на территории «починить», а когда — на территории «начать заново».

Три признака того, что пересобрать действительно стоит

1. Изменилась основная идея, а не просто функции

Если вы начинали строить инструмент для приёма клиентов, а теперь хотите B2B SaaS с подписками, командами пользователей и публичным маркетплейсом — это другое приложение. Та же технология, совершенно другой продукт. Пытаться превратить одно в другое, наслаивая функции, — всё равно что превращать велосипед в автомобиль, докручивая детали. В итоге получится нечто, что не является ни тем, ни другим.

Вопрос, который стоит задать: Описал бы я это приложение так же, как описывал, когда строил его впервые?

Если ответ «нет» — если название, аудитория и основная ценность отличаются от того, что вы изначально строили, — пересборка, вероятно, и есть верное решение. Вы получаете возможность проектировать под то, что вам реально нужно, вместо того чтобы латать вокруг того, что вы строили под другое.

2. ИИ больше не ориентируется в приложении

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

Когда вы замечаете, что каждое изменение ломает что-то, не связанное с ним, или что ИИ снова и снова совершает одну и ту же ошибку (например, неверно определяет, к какой части приложения относится функция), — возможно, вы перешли на территорию «структурного долга».

Пересборка не решает это по волшебству — но она позволяет строить начисто с самого начала, держа в голове полную картину.

3. У приложения есть пользователи, но оно их сдерживает

Если реальные люди пользуются вашим приложением, а вы всё время упираетесь в одну и ту же стену — «нам нужно X, но добавить это невозможно, не переделав всё», — это законный сигнал к пересборке. Не потому, что приложение плохое, а потому, что оно было построено под меньшую версию проблемы, чем та, которую вам реально нужно решить.

Это хорошая проблема. Она означает, что приложение работало достаточно хорошо, чтобы люди пользовались им всерьёз. Пересборка на этом этапе — не провал, а выпускной.

Что сделать, прежде чем пересобирать

Даже если вы решили пересобирать, сначала сделайте вот что:

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

Запишите, что вызывало проблемы. Не просто «это тормозило» или «это часто ломалось» — будьте конкретны. «Функция заметок конфликтовала со сценарием записи, потому что обе хранили данные в одной и той же записи пользователя». Вы хотите унести уроки, а не код.

Задайте границу объёма для пересборки. Самый большой риск при пересборке — расползание объёма. Вы решаете переделать всё, и два месяца спустя всё ещё не закончили, потому что продолжаете добавлять функции «раз уж мы тут». Пересборка должна выкатить рабочие функции из старого приложения плюс одну-две вещи, которые были по-настоящему заблокированы. Всё остальное добавляется потом.

Когда продолжать дорабатывать (в большинстве случаев)

Приложение медленно грузится? Дорабатывайте — обычно это проблема запроса к данным или слишком много всего грузится разом.

Дизайн выглядит устаревшим? Дорабатывайте — обновление дизайна на 100% выполнимо в ИИ-конструкторе, не трогая нижележащую логику.

Ключевая функция ощущается неуклюжей? Дорабатывайте — пересоберите только эту функцию, а не всё приложение.

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

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

Приложение Марии

Мы прошлись по её приложению вместе. Основная структура — клиенты, приёмы, платежи — была на самом деле в порядке. Беспорядок шёл от функции заметок, которая была прикручена так, что конфликтовала с тем, как хранились записи о клиентах.

Вместо пересборки она сказала ИИ-конструктору ровно то, что происходит: «Раздел заметок и сценарий записи хранят информацию в пересекающихся местах, и это вызывает конфликты. Я хочу перестроить заметки так, чтобы они были полностью отделены от записи о брони». Через две сессии всё было исправлено. Остальная часть приложения осталась нетронутой.

Полгода накопленных функций — не потеряны.

Настоящий вопрос

Прежде чем решить пересобирать, спросите: Проблема в приложении или в моей ясности насчёт того, что приложение должно делать?

В большинстве случаев ответ — в ясности. А ясность не требует пересборки. Она всего лишь требует быть конкретным с вашим ИИ-конструктором насчёт того, что вы на самом деле хотите.

Начните с этого. Пересборка всегда доступна. Она никуда не денется и через неделю.

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