Коли ваш застосунок на ШІ переростає першу ітерацію: рефакторинг проти переписування

Ви випустили щось. Користувачі полюбили. Тепер користувачів десять, і вони хочуть функцій, що не вписуються в початкову форму. Ви стоїте на роздоріжжі: латати застосунок під новий сценарій чи визнати, що перша версія була прототипом, і збудувати правильно. Це запитання, що вбиває більше маленьких проєктів, ніж будь-яке інше, бо немає технічної відповіді — лише бізнесова.

Момент, коли ви усвідомлюєте, що застосунок успішний

Більшість застосунків на ШІ починається як одне й стає іншим. Ви збудували форму прийому клієнтів для своєї коучингової практики; тепер клієнти хочуть бачити минулі прийоми й перепризначати їх самі. Ви збудували інструмент оцінки лідів; тепер ваша команда продажів хоче зведення, експортовані в їхню CRM. Ви збудували систему зберігання; тепер люди хочуть співпрацювати всередині неї.

Кожен запит розумний. Кожен трохи відтягує застосунок від того, чим він був збудований бути. І в певний момент — за пів року, чи за два місяці, іноді за два тижні — ви відчуваєте тертя. Усе, що ви додаєте, бореться з фундаментом. Нові функції вимагають «о, нам треба спершу реорганізувати ту частину». Застосунок сповільнюється. Змінювати речі стає довше.

Це відчуття — ваш сигнал подумати, чи це все ще той самий застосунок, чи ви його переросли.

Що рефакторинг купує й коштує

Рефакторинг означає лишити той самий застосунок, але прибрати в ньому, щоб ви могли будувати більше зверху. Ви просите свій конструктор на ШІ реорганізувати код, розділити надскладний робочий процес чи переробити екран, що став звалищем функцій. Це займає кілька годин. Це не додає нових функцій. Це просто робить фундамент міцнішим.

Коли рефакторинг працює, це магія. Ви відчували, що боретеся з застосунком; раптом ви не боретеся. Ви додаєте три нові функції за тиждень, що раніше зайняли б три тижні.

Але рефакторинг працює, лише якщо проблема — у формі того, що у вас є. Якщо ви збудували форму прийому, а користувачі хочуть швидшу форму прийому, рефакторити повільну частину — це один день. Якщо вони хочуть форму прийому, що швидша й зберігає історію, це все ще один застосунок, і рефакторинг може допомогти. Але якщо вони хочуть історію прийомів, інтеграції з календарем, SMS-нагадування й виставлення рахунків, ви вже будуєте не кращу форму прийому — ви будуєте бек-офіс для коучингової практики. Це інший продукт.

Що переписування купує й коштує

Переписування означає: ви дізналися, чим застосунок насправді має бути, і збираєтеся збудувати його з нуля з цим знанням. Ви не викидаєте першу версію — ваші користувачі все ще від неї залежать. Але ви будуєте новий застосунок з фундаменту, поінформований тим, чого навчив старий, а потім переносите користувачів, коли він готовий.

Переписування відчувається марнотратним. Ви збудували щось, а тепер будуєте знову. Це психологічна ціна. Практична ціна — час: ви витратите два-чотири місяці на нову версію, перш ніж вона буде готова переносити користувачів. У вас більше не буде першої версії як милиці — ви рухаєтеся вперед без страховки.

Але переписування купує вам одну річ, яку ніщо інше не може: свободу. Новий застосунок не обмежений формою старого. Якщо оригінал був простою формою, а новий має бути повним бек-офісом, ви проєктуєте під це з самого початку. Якщо продуктивність важить, ви проєктуєте під це. Якщо безпека, чи інтеграції, чи робочий процес важать, вони не доробки — вони фундаментальні.

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

Три запитання, щоб обрати між ними

Запитання 1: Чи основна форма все ще правильна?

Ваша основна форма — це один-два головні робочі процеси, що визначають застосунок. Для форми прийому коучингу це «клієнт заповнює прийом, коуч переглядає, коуч призначає». Якщо ви додаєте інші робочі процеси — рахунки, керування календарем, спілкування з клієнтами, — ви не розширюєте ядро, ви прикручуєте побічні функції. Це ознака, що ви будуєте інший продукт, що означає переписування.

Якщо ви додаєте варіації того самого ядра — «прийом для окремих людей, прийом для команд, прийом із кастомними полями», — це все ще той самий застосунок. Рефакторте й розширюйте його.

Запитання 2: Якщо ви рефакторите сьогодні, скільки ще місяців до того, як тертя вдарить знову?

Будьте чесні. Якщо тертя зникне на пів року, рефакторинг — правильний хід. Якщо воно знову болітиме за два місяці, бо проблема не у формі коду, а в самому фундаменті, тоді переписування заощаджує вам фальшиву економію латання двічі. Запитайте свій конструктор на ШІ: «Якщо ми тут приберемо, як довго, доки нам не треба буде робити це знову?» Якщо відповідь — «імовірно, недовго», час перебудовувати.

Запитання 3: Від чого ваші користувачі насправді залежать?

Якщо у вас троє активних користувачів на v1 і ви думаєте про перебудову, ви можете перенести їх за день-два. Якщо у вас п’ятдесят користувачів, що продакшен-залежні від поточного застосунку, переписування означає, що вам доведеться тримати обидві версії робочими місяцями, що свій вид болю.

Шлях, що зазвичай працює

Більшість засновників, що успішно перебудовують, роблять це паралельно: вони тримають оригінальний застосунок робочим і використовують вільну пропускну спроможність, щоб будувати новий. Коли новий має паритет функцій зі старим, вони витрачають тиждень на перенесення даних і користувачів, і вони готові.

Шлях, що зазвичай не працює: рефактор, рефактор, рефактор, доки на третьому рефакторі ви не зрозумієте, що архітектура все ще неправильна, а тепер ви надто вклалися в «стару» версію, щоб визнати це й почати спочатку.

Правильний час вирішувати

Наступного разу, коли ви відчуєте тертя, запитайте себе: «Я змушую цей застосунок робити те, для чого він призначався, краще? Чи я прошу його бути чимось, для чого він ніколи не проєктувався?» Якщо перше — рефакторте. Якщо друге — немає сорому в тому, щоб збудувати річ, якою вона мала бути з самого початку. Більшість успішних застосунків — на версії 2 ядра, а не на версії 1.