Когда один человек делает первый MVP, цель почти никогда не в “идеальной архитектуре”. Цель — как можно быстрее проверить, нужен ли продукт рынку.

На этом этапе у тебя обычно:

мало денег,
мало пользователей,
мало времени,
почти нет операционного ресурса.

И тут возникает первый архитектурный выбор:

Полностью кастомный путь — свой сервер, свое приложение, своя БД, своя логика регистрации, свои деплои.
Облачный путь — managed hosting, managed auth, managed DB, hosted payments.

Оба подхода нормальны. Плох не подход, а выбор не под свою стадию.

Главная мысль

Для новичка в архитектуре важно понять простое правило:

Архитектура на старте — это не про “как правильно навсегда”.Это про “какой уровень сложности оправдан прямо сейчас”.

Если ты строишь слишком рано “как у большой компании”, ты утонешь в сложности.

Если ты слишком долго сидишь на примитивном решении, рост продукта начнет ломать бизнес.

Подход 1. Полностью кастомное решение

Это классический старый путь:

купил VPS,
поднял приложение,
поставил БД,
настроил домен,
настроил SSL,
деплоишь руками,
сам хранишь пользователей,
сам работаешь с платежами.

Как это выглядит

flowchart LR
    U[Пользователь<br/>Браузер / Телефон] --> DNS[Домен / DNS]
    DNS --> NET[Интернет]
    NET --> FW[Firewall 80/443]

    subgraph VPS[Один VPS / одна VM]
        FW --> RP[Reverse Proxy<br/>Nginx / Caddy]
        RP --> APP[Монолитное приложение<br/>UI + API + Admin]
        APP --> DB[(SQL БД)]
        APP --> FS[Локальные файлы<br/>logs / uploads]
    end

    DEV[Разработчик] --> GIT[Git]
    GIT --> DEPLOY[SSH / rsync / docker compose]
    DEPLOY --> VPS

    APP --> SMTP[Email / SMTP]
    APP --> PAY[Платежный провайдер]

Это самый прямой путь.

Всё под твоим контролем. Всё на тебе же.

Что здесь хорошо

1) Максимальный контроль

Ты сам решаешь:

как устроен backend,
как хранить данные,
как делать деплой,
как выглядят регистрация, роли, сессии, платежный флоу.

Это полезно, если тебе реально нужен нестандартный сценарий.

2) Понятная база для обучения

Для новичка это лучший способ увидеть “физику системы”:

DNS
HTTP
reverse proxy
app process
DB connection
migrations
backup
SSL
логирование
фоновые задачи

То есть ты видишь путь запроса целиком.

3) Меньше vendor lock-in

Если ты всё собрал сам, тебе проще переносить систему между провайдерами.

4) Иногда дешевле на раннем старте

Если пользователей очень мало, один дешевый VPS может стоить меньше, чем набор из нескольких managed-сервисов.

Что здесь плохо

1) Ты платишь временем и вниманием

Каждая “мелочь” становится твоей задачей:

обновления сервера,
SSL,
firewall,
бэкапы,
ротация логов,
мониторинг,
восстановление после сбоя,
безопасность,
почта,
хранение паролей,
rate limiting.

То, что в облаке “уже есть”, здесь ты делаешь сам.

2) Ошибки здесь дороже

Новичок чаще всего ошибается не в коде, а в эксплуатации:

открыл лишний порт,
не сделал backup restore test,
не ограничил доступ к БД,
держит секреты в коде,
хранит пароли неправильно,
доверяет callback от оплаты без валидации.

3) Ты быстро становишься “и разработчиком, и DevOps, и SRE”

Если у тебя MVP для проверки спроса, это может быть невыгодно.

4) Рост ломает такую схему

Один сервер на старте ок. Но дальше начинаются проблемы:

CPU упирается в пики,
память забивается,
приложение становится stateful,
БД и приложение конкурируют за ресурсы,
деплой становится рискованным,
любой рестарт = микродоступность вниз.

Когда кастомный путь оправдан

Смотри в эту сторону, если:

ты хочешь научиться базе инфраструктуры;
у тебя очень простой продукт;
у тебя нестандартная бизнес-логика;
тебе важен полный контроль;
ты готов сам обслуживать это;
у тебя не гипотеза “за 3 дня проверить спрос”, а чуть более инженерный pet/MVP.

Примеры:

личный кабинет,
маленький SaaS,
внутренний инструмент,
контентный сайт с простой оплатой,
админка + форма платежа + таблицы.

Когда не стоит выбирать кастомный путь

Вообще не смотри туда, если:

твоя главная цель — максимально быстро проверить спрос, а не учиться инфраструктуре;
ты не хочешь заниматься сервером вообще;
ты не понимаешь базово:
- backup / restore,
- безопасность секретов,
- хранение паролей,
- TLS / SSL,
- сетевой доступ;
продукт завязан на:
- соцлогин,
- email verification,
- reset password,
- антиабуз,
- webhook-интеграции,
- платежи,
  
  и тебе всё это нужно сразу;
ты работаешь один, а времени очень мало.

Если ты новичок и говоришь “я сейчас сам всё соберу: auth, payments, infra, deploy, security” — это часто не архитектура, а самосаботаж.

Подход 2. Облачное / managed решение

Это современный путь:

фронт/сайт хостится на managed платформе,
auth от отдельного сервиса,
БД от managed-провайдера,
платежи — hosted checkout,
деплой — через git push.

Как это выглядит

flowchart LR
    U[Пользователь<br/>Браузер / Телефон] --> DNS[Домен / DNS]
    DNS --> EDGE[Managed Hosting / CDN / SSL]

    EDGE --> FE[Frontend / Web App]
    FE --> API[Serverless API<br/>или Managed Backend]

    API --> AUTH[Managed Auth]
    API --> DB[(Managed DB)]
    API --> PAY[Hosted Payments]
    API --> STORE[Object Storage]

    DEV[Разработчик] --> GIT[Git push]
    GIT --> CI[Автодеплой]
    CI --> EDGE

Здесь ты не строишь всё сам.

Ты склеиваешь готовые сервисы.

Что здесь хорошо

1) Максимальная скорость запуска

Ты выносишь “commodity-проблемы” наружу:

SSL,
деплой,
CDN,
авторизация,
reset password,
social login,
хранение сессий,
платежная страница.

Это сильно ускоряет MVP.

2) Меньше шансов сломать базовую безопасность

Когда auth и payment flow делает специализированный сервис, ты меньше рискуешь сделать грубую ошибку.

3) Меньше операционной нагрузки

Тебе не надо первым делом думать о:

патчах ОС,
nginx-конфиге,
cert renewal,
ручных рестартах,
ночных падениях VPS.

4) Лучше для проверки гипотезы

Если задача — проверить:

будут ли люди регистрироваться,
будут ли платить,
будут ли возвращаться,

то лучше тратить время на:

продукт,
UX,
оффер,
контент,
аналитику,

а не на сервер.

Что здесь плохо

1) Меньше контроля

Ты подстраиваешься под ограничения платформ:

как работает auth,
как устроены callback-и,
какие лимиты у функций,
как устроены connection limits,
какие ограничения по рантайму.

2) Vendor lock-in

Чем глубже ты встраиваешься в конкретный managed-стек, тем дороже потом переезд.

3) “Быстро на старте” не всегда значит “дешево потом”

На very early stage это удобно.

Но если нагрузка становится постоянной и растет, некоторые managed-сервисы начинают стоить неожиданно дорого.

4) Новичок может не понять, как система реально работает

Проблема облака в том, что оно скрывает механику.

Можно быстро запустить продукт и при этом слабо понимать:

где живет состояние,
как работает сессия,
где границы ответственности,
что именно происходит при сбое.

Для обучения это хуже, чем “голый VPS”.

Когда облачный путь оправдан

Выбирай его, если:

тебе нужно очень быстро проверить идею;
ты один;
у тебя почти нет ops-ресурса;
у тебя типовой продукт:
- лендинг,
- кабинет,
- подписка,
- контент,
- простая SaaS-логика;
тебе нужна:
- регистрация,
- Google login,
- email verification,
- платежи,
- файлы,
  
  и ты не хочешь писать всё это сам;
для тебя сейчас главное — сократить time-to-market.

Когда не стоит выбирать облачный путь

Не смотри туда, если:

тебе нужен жесткий контроль над инфраструктурой;
у тебя есть требования по:
- кастомной сети,
- приватным сегментам,
- нестандартной топологии,
- требованиям комплаенса,
- точному контролю хранения данных;
у тебя тяжелая, постоянно загруженная система, где managed-платформа становится дорогой;
у тебя сложные long-running процессы, нестандартные воркеры, тяжелая stateful-нагрузка;
ты понимаешь, что через месяц-два тебе нужно будет много низкоуровневого контроля.

Иными словами: если продукт уже не “MVP для проверки спроса”, а почти готовый серьезный backend с особыми требованиями, некоторые “волшебные” облачные решения начнут мешать.

Регистрация пользователей: своя или через managed auth

Это один из первых реальных выборов.

Вариант A: регистрация внутри своего сервиса

sequenceDiagram
    participant User as Пользователь
    participant App as Приложение
    participant DB as БД
    participant Mail as Email

    User->>App: POST /register
    App->>DB: Создать пользователя
    App->>DB: Сохранить hash пароля
    App->>Mail: Отправить confirmation email
    Mail-->>User: Письмо
    User->>App: Подтверждение email
    App->>DB: Активировать аккаунт

Плюсы

полный контроль;
можно сделать любую модель пользователей;
нет зависимости от внешнего auth-провайдера.

Минусы

пароль, reset password, подтверждение email, сессии, защита от абуза — всё на тебе;
легко ошибиться в security;
это редко является ключевой частью MVP.

Вариант B: отдельный cloud auth

sequenceDiagram
    participant User as Пользователь
    participant Browser as Браузер
    participant Auth as Managed Auth
    participant Google as Google
    participant App as Приложение
    participant DB as БД

    User->>Browser: Нажимает "Войти через Google"
    Browser->>Auth: Старт входа
    Auth->>Google: OAuth redirect
    Google-->>User: Подтверждение
    Google-->>Auth: Token / identity
    Auth-->>Browser: Session
    Browser->>App: Запрос с токеном
    App->>Auth: Валидация
    Auth-->>App: OK
    App->>DB: Создать / обновить профиль

Плюсы

запуск намного быстрее;
меньше security-рутины;
social login из коробки.

Минусы

меньше контроля;
возможны ограничения по кастомизации;
зависимость от внешнего сервиса.

Практическое правило

Если auth не является core-функцией продукта — обычно не пиши его сам на старте.

Оплата: своя форма или hosted checkout

Для новичка это еще более критично.

Вариант A: своя логика вокруг платежей

Важно: “своя логика” не значит “сам обрабатываю карты”.

Обычно это значит, что ты сам строишь свой payment flow, статусы, retry, обработку callback.

sequenceDiagram
    participant User as Пользователь
    participant App as Приложение
    participant DB as БД
    participant Pay as Платежный провайдер

    User->>App: Нажимает "Оплатить"
    App->>DB: Создать payment = pending
    App->>Pay: Создать платеж
    Pay-->>User: Платежная форма / редирект
    Pay->>App: Webhook / callback
    App->>DB: payment = paid / failed

Плюсы

больше контроля над UX и состояниями;
можно глубже встроить это в доменную модель.

Минусы

больше шансов сломать обработку статусов;
idempotency, retries, webhook safety — это уже не “мелочи”.

Вариант B: hosted checkout

Ты не рисуешь payment UI сам.

Ты переадресуешь пользователя на готовую платежную страницу.

Плюсы

быстрее;
безопаснее;
меньше кода;
меньше шансов сделать опасную ошибку.

Минусы

меньше кастомизации;
UX частично не твой.

Практическое правило

Для MVP hosted checkout почти всегда выигрывает.

Прямая разница между двумя стратегиями

Если говорить совсем просто

Полностью кастомный путь

Ты покупаешь контроль ценой сложности.

Облачный путь

Ты покупаешь скорость ценой зависимости и ограничений.

Что выбрать новичку в архитектуре

Если ты только начинаешь мыслить как архитектор, не надо пытаться сразу “выиграть навсегда”.

Надо научиться задавать правильные вопросы.

Вот правильный порядок.

Вопрос 1. Что я сейчас оптимизирую?

Если ответ:

“хочу быстро проверить спрос” → облако чаще лучше.
“хочу понять, как всё устроено” → кастомный путь полезнее.
“мне нужен нестандартный контроль” → кастомный путь вероятнее.
“мне надо за неделю открыть доступ людям и принять первую оплату” → managed путь чаще лучше.

Вопрос 2. Что для меня дороже: время или контроль?

Если у тебя:

мало времени,
мало ресурса,
нет DevOps-опыта,

то “полный контроль” часто не помогает, а мешает.

Вопрос 3. Я строю продукт или инженерный полигон?

Это важный вопрос.

Иногда человек говорит “я делаю MVP”, а на деле строит учебный стенд:

свой auth,
свои деплои,
свои очереди,
свои воркеры,
свою наблюдаемость,
свои админки.

Если цель — заработать или проверить идею, это часто ошибка.

Если цель — научиться архитектуре и платформе, это может быть нормой.

Когда какой путь особенно плох

Это важнее, чем “когда хорош”.

Плохой кастомный старт

Кастомный путь плох, когда:

ты валидируешь гипотезу;
тебе нужен быстрый запуск;
ты один;
продукт типовой;
твой bottleneck — не инфраструктура, а рынок.

В такой ситуации “свой VPS + свой auth + своя платежка + своя почта” — это часто не смелость, а лишняя сложность.

Плохой облачный старт

Managed-путь плох, когда:

у тебя уже понятная нагрузка и важна экономическая эффективность;
тебе нужен низкоуровневый контроль;
доменная логика упирается в особенности инфраструктуры;
ты уже заранее знаешь, что платформа будет жать по ограничениям.

В такой ситуации “давайте всё соберем на удобных managed-сервисах” может привести к дорогому и болезненному переезду.

Самая здравая стратегия для большинства MVP

Для большинства реальных MVP у одного человека самый рациональный путь такой:

Не писать commodity-части самому
- auth
- email verification
- reset password
- hosted checkout
- SSL
- CDN
Писать самому только core value
- твоя бизнес-логика
- твой UX
- твоя доменная модель
- твои сущности
- твои сценарии продукта
Держать архитектуру простой
- один deployable app
- одна БД
- минимум фоновых процессов
- минимум moving parts

То есть:

не надо путать “простую архитектуру” с “всё написано вручную”.

Простая архитектура — это когда у системы мало критичных частей.

Даже если часть из них managed.

Как бы я объяснил это совсем коротко

Если ты хочешь учиться инженерии глубже — подними один VPS и собери всё руками.
Если ты хочешь быстро проверить продукт — бери managed-стек и не усложняй.
Если ты хочешь и то, и другое, раздели цели:
- один проект как учебный стенд,
- другой как реальный MVP.

Не надо пытаться одной системой одновременно:

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

Обычно так не бывает.

Диаграмма выбора

flowchart TD
    A[Есть идея продукта] --> B{Главная цель?}

    B -->|Быстро проверить спрос| C[Managed / Cloud путь]
    B -->|Понять инфраструктуру глубже| D[Кастомный путь]
    B -->|Нужен полный контроль| D

    C --> E{Есть особые требования<br/>по сети, комплаенсу, рантайму?}
    E -->|Нет| F[Managed auth + managed DB + hosted payments + простой app]
    E -->|Да| G[Смешанный вариант<br/>часть managed, часть custom]

    D --> H{Есть опыт сопровождения?}
    H -->|Да| I[Один VPS / один app / одна DB]
    H -->|Нет| J[Лучше упростить цель<br/>или уйти в managed]

    F --> K[Быстрое MVP]
    G --> K
    I --> L[Учебный / контролируемый MVP]
    J --> K

Итог

Для новичка в архитектуре ключевая ошибка — выбирать не под стадию продукта, а под амбицию.

Кастомный путь хорош, когда нужен контроль, обучение, гибкость.

Облачный путь хорош, когда нужна скорость, простота запуска и минимум операционной боли.

На старте обычно выигрывает не тот, у кого “архитектура круче”, а тот, кто:

быстрее дошел до пользователей,
быстрее получил обратную связь,
не утонул в лишней сложности.