Судя по моим наблюдениям, стартапы схлопывается не из-за плохого маркетинга, или неудачной идеи. Они в основном буксуют из-за плохих технических решений, принятых в самые первые месяцы.

Вот три самых опасных:

1. “Микросервисы с первого дня” Команда из 3 человек не должна поддерживать 15 сервисов. И не нужно оправдывать это “подготовкой к масштабированию” - это просто самоубийство. Лучше начать с модульного монолита - он даёт ту же самую модульность и четкие границы контекста , но без операционного ада с поддержкой, развертыванием, мониторингом и скейлингом кучи микросервисов. Разделить можно потом, когда поймёте где реальные границы доменов, и когда это действительно будет необходимо - при росте трафика, или при росте команды.

2. “Напишем своё вместо готового” “А давайте запилим кастомную авторизацию”, или еще лучше - “Давайте сделаем самописный платёжный процессинг”. А может “уникальный" CI/CD пайплайн? Каждая такая “экономия” - это месяцы технического долга, которые вы будете выплачивать вместо того, чтобы строить продукт. Не нужно оправдывать это увеличением ценности продукта, вы схлопнитесь раньше, чем сможете эту ценность донести инвесторам. Есть простое и проверенное правило: Build if it’s core to your business; buy if it isn’t.

3. “Рефакторинг подождёт до раунда” Нет, не подождёт. Технряеский долг растёт экспоненциально. То, что сегодня занимает день на исправление, через полгода потребует переписать половину системы. А инвесторы на due diligence это точно увидят, поверьте мне.

Самое обидное, что все эти неудачные решения принимаются из лучших побуждений. “Хотели сделать правильно”, “готовились к росту”, “не было времени”.

Лучшая архитектура для стартапа -  та, которую можно изменить за неделю, а не та, которая “правильная по книжке”.