Надзвичайно неоднозначний посібник із вибору технологій для MVP стартапу

Я був відповідальним за створення близько 6 серйозних стартапів MVP з нуля і близько 5 домашніх проєктів. Деякі з них пройшли чудово, а деякі зазнали невдачі ще до запуску. Мої помилки змусили мене сформувати тверду думку про те, які технології я хочу використовувати у своєму наступному MVP, і я вірю, що це єдина правильна технологія, яка не має гідних альтернатив.

KPI

Перш ніж переходити до переможців, ми повинні визначити критерії перемоги. Ми працюємо над створенням MVP-стартапу. Це означає, що швидкість розробки та ком'юніті є основними KPI. Нас не цікавить якість мови. Нам також не важливо наскільки вона інноваційна. Нам не важливо наскільки вона масштабована. Я розумію, що ви хочете мати можливість обробляти мільйони користувачів за секунду і, повірте мені, з сучасними архітектурними стеками будь-яка мова може це робити, але різниця буде в ціні. І коли ви ставите своїм основним KPI "Вартість архітектури", тоді поговорімо про її оптимізацію. Зазвичай "Вартість архітектури" і "Швидкість доставки" — це досить протилежні KPI. Не помиліться та оберіть правильні KPI для MVP.

Отже, наш основний KPI —"Швидкість доставки", а критерії, за якими ми вимірюємо мову, —"швидкість розвитку" та "спільнота".

Мови

Це буде залежати від того, яке рішення ви створюєте, але в 99% випадків ви будете використовувати JS на фронтенді. Якщо ви хочете створити WEB-додаток, JS — єдиний варіант. Якщо ви хочете створити мобільний додаток, ви можете використовувати рішення на основі JS за допомогою React Native, рішення на основі Dart за допомогою Flutter або нативний додаток за допомогою Swift і Kotlin. Створення нативного додатку вимагатиме від вас створення 2 окремих додатків для 2 платформ, що занадто довго для стартапу. Flutter vs React Native —це своєрідне змагання мемів. У мене був досвід використання обох, і React Native переміг, тому що у нього більше розробників, більше бібліотек і простіша кодова база. Чесно кажучи, я ніколи не створював десктопних додатків і навряд чи можу уявити, що хтось захоче створити десктопний додаток у 2023 році, але навіть якщо ви це зробите, ви, ймовірно, захочете, щоб він працював на всіх операційних системах, тому ви, скоріш за все, захочете використовувати Electron, який, знову ж таки, використовує JS.

Отже, що б ви не робили, ви будете використовувати JS на фронтенді.

З бекендом трохи цікавіше, тому що у нас є 2 кандидати: JS та Python. Більше не існує жодної мови для створення бекенду для стартапу MVP. Ні Java, ні Golang, ні Rust. Ось чому ця стаття так називається. Але, дозвольте мені висловити свою думку. І JS, і Python вважаються найпростішими мовами у світі. Вони обидві мають найбільшу кількість розробників і найбільшу кількість бібліотек, тому вони є беззаперечними переможцями за нашими критеріями.

Тепер є просте дерево рішень, яке ви можете використовувати для вибору між ними: якщо ви будуєте стартап, пов'язаний з даними, або плануєте навчати власний AI, або створюєте скраппер — використовуйте Python. У всіх інших випадках використовуйте JS.

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

Якщо ваш стартап пов'язаний з даними, використовуйте Python, у всіх інших випадках —JS.

Чому JS у всіх інших випадках? Переваги, які дає вам інфраструктура з однією мовою, величезні. Будь-який з ваших бекенд/фронтенд розробників тепер стає повноцінним стеком. Full-stack розробник —це єдиний розробник, якого вам потрібно мати для стартапу. Вам не потрібні спеціалісти, вам потрібні універсали, які можуть впоратися з усім. JS — ідеальна мова в цьому випадку.

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

Звичайно, JS не ідеальний, і це трохи смішно, коли справа доходить до зміни коду, який ви написали. А ви хочете змінити код. Ви хочете робити зведення, і ви хочете повторно використовувати свій код під час зведення. Ось чому існує TS. TypeScript (TS) — це розширення JS, яке дозволяє додавати в мову strict types. Уявіть собі, що це син JS та C#. З TS ви отримуєте потужність C# разом з простотою JS. Потужна комбінація, яка робить ваш JS стек масштабованим. 100 розробників можуть працювати над вашим кодом, і всі вони будуть розуміти код і зможуть підтримувати його завдяки типам.

У 2023 році буде прийнято використовувати TS. Якщо ви плануєте використовувати JS, використовуйте TS.

Фреймворки

При використанні TS framework stack простий і не потребує коментарів:

• WEB - React + Redux Toolkit OR Next.JS
• Mobile - React Native + Redux Toolkit
• Desktop - Electron
• Backend - Nest.JS

Ви можете сказати, що Svelte або Vue.js солодший, але тоді я скажу, що вам пощастило знайти розробників, які його підтримують. Вони є, але ви точно не захочете скоротити 90% ринку розробників, обравши якийсь дивний унікальний фреймворк або технологію.

Я люблю Nest.JS через архітектуру, яку він змушує вас використовувати. Вам не потрібен ступінь CS, архітектори рішень та UML-діаграми, щоб побудувати дивовижну архітектуру бекенду, вам потрібен лише Nest.JS. Коли я починав свій проєкт на Nest.JS, я просто прочитав всю документацію, і після цього у мене не виникло жодних проблем з кодом. Звичайно, ми також використовували TS, літери, ретельно контролювали залежності, писали міграції та намагалися слідувати чистому коду.

Довша розмова — це бібліотека компонентів, яку ви будете використовувати. Просто використовуйте деякі, не намагайтеся створювати компоненти з нуля. Це довго і воно того не варте, принаймні для MVP. Іноді засновники закінчують розробку дизайну і вимагають від розробників реалізувати його. Не робіть цього, якщо ви просто будете використовувати поширені бібліотеки компонентів дизайну, такі як Material UI, Ant design або хоча б Tailwind, ви створите MVP в 3 рази швидше, і це відмінний компроміс, якщо припустити, що "Швидкість доставки" є нашим основним KPI.

Використовуйте бібліотеку компонентів, неважливо яку, але не використовуйте Bootstrap — це звучить як 2001.

База даних також має певну гнучкість. Сучасні full-stack розробники віддають перевагу MongoDB, я ж олдскульний хлопець, який любить SQL і Postgres. Mongo ідеально підходить для аналітики даних та скрапінгу, коли ви хочете зберігати дані у неформатованій структурі. Однак, як основна DB вона дуже погана. Я відчував величезні проблеми з налаштуванням міграцій на ній, і вона дійсно не була створена для цього. Тому, на мою думку, в проєкті завжди повинна бути SQL DB для високоструктурованих і наперед визначених сутностей, таких як користувачі, ролі, конфігурації та деякі інші специфічні речі. Але якщо у вас є якісь дивні дані, ви можете використовувати Mongo для цього. Якщо ви шукаєте більшої гнучкості в Postgres, є тип даних JSON, який вставляє повну структуру даних в DB і автоматично серіалізує їх, використовуючи ORM, наприклад, TypeORM.

Навіть якщо ви створюєте соціальні мережі і думаєте, як я зможу обійтися без GraphDB і key value DB, а також DB часових рядів для аналітики, просто не робіть цього. В майбутньому у вас буде бюджет на оптимізацію всього цього, і це чудово, що ви маєте таке масштабоване бачення, але для MVP просто використовуйте Postgres, він може впоратися з усім.

Тож не вигадуйте велосипед, не ускладнюйте свою інфраструктуру і не будьте занадто легковажними з DB, просто використовуйте PostgreSQL.

Перевірка здоров'я стартапу

На основі всього раніше обговореного ми з'ясували, що є багато речей, які можуть піти не так при створенні або розширенні MVP. Щоб допомогти іншим технічним директорам та засновникам будувати стартапи, не боячись технічних ризиків, я розробив Healthcheck, який є набагато менш безглуздим і набагато більш узагальненим, щоб його можна було застосувати до будь-якого стартап-проєкту. Я особисто організовую цей Healthcheck для кожного стартапу, з яким працюю, принаймні раз на 6 місяців.

Ви можете спробувати пройти його за цим посиланням — https://foil-millennium-d85.notion.site/Startup-MVP-development-Healthcheck-56b42f307c6d490780966dc27053e51b