Метаисследование · 18 июля 2026 г.
Карта роста инфраструктуры солопренера: что менять и когда
Семь категорий платформ складываются в одну операционную карту — от прототипа, который должен безопасно отказать, до приносящей деньги системы с проверенными восстановлением, лимитами и unit economics.
Методика
Что именно сравнивается
- Объединяем шесть исследований по одним критериям: cost control, observability, portability и эксплуатационная нагрузка.
- Определяем стадии доказательствами, а не vanity user counts: прототип, первые пользователи, первые деньги, предсказуемый рост и критическая эксплуатация.
- Моделируем месячные диапазоны вместо точек, потому что базы, media, AI и форма трафика определяют точный счёт.
- Рекомендуем класс платформы и trigger миграции, а не универсального победителя.
Первая архитектура оптимизирует дешёвую ошибку
До пользователей правильным отказом обычно является жёсткая остановка. Конструктор, бесплатный BaaS, scale-to-zero runtime и prepaid model budget позволяют проверить спрос без обслуживания сервера и uncapped invoice.[1]
Владение репозиторием, экспорт данных, контроль домена и документированные переменные окружения важнее теоретического масштаба. Они сохраняют возможность переезда после того, как продукт узнает реальную нагрузку.
| Стадия | Что оптимизировать | Необходимые доказательства | Хороший класс по умолчанию |
|---|---|---|---|
| Прототип | Скорость и жёсткая граница расходов | Build работает; данные экспортируются | Prompt builder + бесплатный managed backend |
| Первые пользователи | Ошибки и поддержка | Логи, latency, usage по функциям | Managed PaaS / BaaS |
| Первые деньги | Recovery и unit economics | Backups, restore, cost per action | Платная managed platform |
| Предсказуемый рост | Эффективность и bottlenecks | Capacity profile и измеренные resource hours | Оптимизированный PaaS, cloud service или VPS |
| Критическая эксплуатация | Изоляция и recovery | SLO, fault tests, проверенный failover | Осознанное облако или multi-node design |
Месячный счёт — это диапазон, а не лестница
Контентный продукт способен получить большой трафик рядом с edge free tier. Небольшой AI-продукт может потратить сотни долларов на нескольких активных пользователей. Realtime- или media-backend пересекает квоты egress и connections раньше, чем compute выглядит загруженным.
Диапазоны ниже объединяют предыдущие исследования. Используйте их для разговора о бюджете, а не как прогноз. Верхняя граница включает платную телеметрию, backups и безопасные лимиты вместе с самым дешёвым runtime.
Условия миграции, основанные на доказательствах, а не тревоге
Уходите с prompt-to-app runtime, когда отсутствие логов или cost controls мешает поддержке, а не потому, что generated code вышел из моды. Уходите с PaaS, когда измеренная постоянная стоимость ресурсов или необходимый primitive оправдывают новый уровень эксплуатации. Уходите с managed database, когда premium превышает проверенную стоимость работы и восстановления альтернативы.
Арендуйте GPU после того, как open model прошла продуктовую оценку. Покупайте после стабильно высокого utilisation аренды. Переходите с VPS на dedicated CPU после измерений постоянной contention. Добавляйте redundancy, когда этого требует recovery objective, а не ради украшения архитектуры.
| Текущий класс | Условие на основе данных | Вероятный следующий шаг | Что доказать до миграции |
|---|---|---|---|
| Prompt-to-app | Нельзя объяснить incidents или ограничить расходы | Свой repo на managed PaaS | Повторяемый build и data export |
| Managed PaaS | Постоянный measured premium выше operator cost | VPS или узкий cloud service | Load profile и automated recovery |
| BaaS | Доминирующий meter или отсутствующий database primitive | Композиция сервисов или self-host | Data migration и restore rehearsal |
| Прямой LLM API | Стабильный дорогой demand; open model прошла eval | Арендованная GPU | Quality, throughput и fallback test |
| Арендованная GPU | Высокий постоянный utilisation | Своя GPU | Power, VRAM, depreciation и downtime model |
| Shared VPS | Измеренная contention или capacity ceiling | Dedicated vCPU / bare metal | Benchmark той же нагрузки и recovery plan |
Операционный контракт для одного человека
Каждый production stack должен помещаться на одной странице: компоненты, owner, месячный envelope, hard limits, alert thresholds, расположение данных и backups, recovery steps и deletion steps. Такой inventory связывает риск продукта с действием оператора прямее сложной архитектурной диаграммы.
Пересматривайте её после каждого запуска и месячного invoice. Заменяйте предположения модели измеренными resource series. Если компонент нельзя наблюдать, ограничить, восстановить или предсказуемо удалить, успешный деплой ещё не делает его безопасным.
- Один billing inventory: каждый платный ресурс и условие его удаления.
- Одна cost model: цена продуктового действия и envelope launch spike.
- Один recovery test: восстановление данных и сервиса в пустое окружение.
- Один capacity profile: latency операций, resource headroom и первая ограничивающая зависимость.
Реестр источников
Спецификации и цены меняются. Ссылки делают снимок проверяемым.
Источники и коммерческие данные проверены 2026-07-18. Если источник не говорит обратного, цены указаны без налогов.
- Prompt-to-app SRE field guide ↗CapacityLab · исследование
- Railway vs Fly.io ↗CapacityLab · исследование
- Big cloud for one person ↗CapacityLab · исследование
- VPS, VDS, or dedicated? ↗CapacityLab · исследование
- API, rented GPU, or owned GPU ↗CapacityLab · исследование
- Supabase costs and alternatives ↗CapacityLab · исследование