<b>Vercel удобен ровно до момента, когда проект начинает жить дольше демо</b>

<b>Vercel удобен ровно до момента, когда проект начинает жить дольше демо</b>

За неделю в репах: у Vercel чаще всего ломается не деплой, а ожидание, что «serverless = как обычный бэкенд». На практике там критичны три вещи: размер бандла, холодный старт и границы по времени выполнения.

Если у тебя Next.js-проект, проверь до выката:
— не тащишь ли в edge/runtime тяжёлые SDK;
— не держишь ли соединения с БД в каждом запросе;
— не упираешься ли в image/ISR/cron, которые уводят логику в разные места.

Ещё один типовой просчёт — считать Vercel хостингом «для всего». Для фронта и лёгкой API-обвязки он обычно хорош. Для очередей, фоновых задач, долгих генераций, вебхуков с ретраями и stateful-логики лучше сразу планировать внешний сервис, а не надеяться, что всё уместится в один проект.

Есть наблюдение которое стоит проверить: чем раньше разделишь «публичный веб», «серверную логику» и «хранилище», тем меньше боли при росте. Vercel хорошо склеивает витрину, но архитектурный долг он не прощает.

Если проект начинает зависеть от фоновой работы и нестабильных интеграций, используй Vercel как слой доставки, а не как единственный runtime.