Как избежать излишнего усложнения на ранних этапах развития SaaS-проектов?

Question

[sandeeptech]

Я разрабатываю SaaS-платформу на ранней стадии развития в сфере технологического образования. MVP уже запущен, команда небольшая, и мы все еще проверяем соответствие продукта рынку.
Я хочу избежать излишнего усложнения, принимая архитектурные решения, которые не потребуют серьезной переработки через 6-12 месяцев.
Текущие вопросы:
Монолитная архитектура против микросервисов на данном этапе
Когда следует внедрять очереди и фоновые обработчики
Стоит ли проектировать систему с учетом горизонтального масштабирования до реальной нагрузки
Какой уровень абстракции является разумным на раннем этапе?
Для тех, кто масштабировал SaaS-продукты от MVP до стадии роста:
Какие сигналы указывают на оправданность дополнительной архитектурной сложности?
Какие решения на ранних этапах, как правило, оказываются удачными, а какие обычно превращаются в ненужные накладные расходы?

Comments

[Everything_is_bad]

Слишком много вопросов и они очень общие.

Answer 1

[rPman]

У меня есть непопулярное мнение, но оно имеет смысл, для любого крупного продукта, невозможно предугадать заранее что с ним будет. Если цикл разработки у вас годы, платит вам крупных заказчик или государство, и техническое задание это часть вашей разработки (обычно это напрямую связано), делите этап на части, запускайте пилотный проект как получится, отлаживайте на нем все нюансы и тонкости, но главное будьте готовы что этот продукт через 1-2 года ДОЛЖЕН быть сброшен в утиль и заменен новым, ТЗ которого создано в процессе разработки и эксплуатации этого первого прототипа.

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

Если заказчик - вы сами, и вы сами занимаетесь реализацией, то... какие нафиг правильные способы разработки, обычно тут либо вы успеваете либо вылетаете с рынка. А если вы единственный в нише, то.. все равно, ваш трон будет таковым не долго, если вы станете успешным. Скорость разработки к сожалению ценится выше чем ее 'правильная' поддержка.. главное помните что все что вы разработаете сейчас будет заменено (не рефакторинг а именно новый продукт), психологически будет проще.

Comments

[VoidVolker]

Всё абсолютно верно. Единственно, что добавлю: самые большие сложности обычно не в самой разработке, а в топ-менеджерах с их "вот-прямо-сейчас" хотелками и другими фантазиями различного толка, а так же всяких других желающих присосаться к бюджету и ничего не делать или только делать вид что что-то делают (ага, встречается, но что поделать).

Answer 2

[VoidVolker]

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