Требуется развернуть в продакшн готовое SaaS-приложение. Код написан и находится в приватном репозитории GitHub (126 файлов), новая разработка не требуется — нужен деплой, настройка инфраструктуры и доведение до стабильно работающего состояния.
Стек
Next.js 14 (App Router, JavaScript без TypeScript), Supabase (Postgres + Auth), BullMQ + Redis (Upstash), Playwright в Docker, Paddle (merchant of record), Resend, Sentry.
Что нужно сделать
1. Supabase: создать проект, применить готовую схему из репозитория (supabase/schema.sql), включить Email OTP авторизацию, проверить RLS-политики.
2. Vercel: импортировать репозиторий, настроить переменные окружения (14 шт., полный список в ТЗ), подключить домен и SSL.
3. Railway: развернуть два сервиса на готовом Dockerfile — постоянный воркер очереди и cron-сервис ежемесячных задач. Проверить работу Playwright/Chromium в контейнере.
4. Upstash Redis, Resend (верификация домена, SPF/DKIM), Sentry — подключение и проверка.
5. Paddle: интеграция чекаута и вебхуков, тесты в sandbox (создание и отмена подписки, неуспешный платёж), затем переключение на боевой аккаунт.
6. Исправить три известные проблемы репозитория (детально описаны в ТЗ): отсутствует package-lock.json при использовании npm ci в Dockerfile; в 19 файлах остались ссылки на старый домен; установка Chromium в Dockerfile идёт с «|| true» и может тихо не сработать.
7. Прогнать калибровочный скрипт и тесты из репозитория, вручную проверить 10 отчётов.
8. Сдать краткий runbook (2–4 страницы): как выкатить обновление, где смотреть логи, что делать при типовых сбоях.
Критерии приёмки
• Полный путь работает end-to-end на боевом домене: скан → отчёт → письмо → оплата тестовой картой Paddle.
• Вебхук создаёт подписку; отмена в Paddle синхронизирует статус.
• Публичные страницы индексируемы и присутствуют в sitemap.
• Sentry получает тестовые ошибки из веб-приложения и из воркера.
• Cron ставит задачи в очередь, воркер их разбирает.
• Ни одного упоминания старого домена в продакшн-сборке.
Порядок работы и оплаты
Работа разбита на этапы. По каждому этапу: исполнитель делает — заказчик проверяет по критериям — оплата этапа. Предоплаты нет; оплата производится за каждый принятый этап.
Этап Содержание Что проверяем при приёмке
1 Supabase, Redis, внешние сервисы (пункты 1 и 4) Схема применена, авторизация работает, ключи выданы заказчику
2 Vercel, домен, исправление проблем репозитория (пункты 2 и 6) Сайт открывается на боевом домене, сборка проходит, старый домен нигде не упоминается
3 Railway: воркер и cron (пункт 3) Тестовый скан выполняется до конца, cron ставит задачи в очередь
4 Paddle: sandbox и боевой режим (пункт 5) Тестовая оплата проходит, вебхуки создают и отменяют подписку
5 Калибровка, тесты, runbook (пункты 7 и 8) Тесты зелёные, отчёты корректны, документация передана
Разбивку на этапы и стоимость каждого предлагает исполнитель в отклике — приведённая таблица является ориентиром и может быть уточнена.
Условия
• Все доступы (Vercel, Supabase, Railway, Paddle, домен) оформляются на аккаунты заказчика, исполнитель приглашается участником. Код, инфраструктура и данные принадлежат заказчику.
• Подробное ТЗ (5 страниц) с полным списком переменных окружения и описанием известных проблем высылаю в личные сообщения по запросу.
• Ключи внешних API и оплату сервисов обеспечивает заказчик.
• Коммуникация: мессенджер и один короткий созвон в неделю. Язык: русский или английский.
Не входит в задачу
Разработка новых функций, изменение продуктовой логики, дизайн, тексты интерфейса, маркетинг, наполнение контентом, работа с клиентами.
Прошу указать в отклике
1. Опыт с Next.js App Router, Supabase RLS, BullMQ, Playwright в Docker, вебхуками Paddle — с примерами проектов.
2. Предлагаемую разбивку на этапы со сроком и стоимостью каждого.
3. Какие риски вы видите по описанию выше и что может занять больше времени, чем кажется.
Отклики без ответов на эти три вопроса не рассматриваю.
Опубликован 18.08.2026 в 13:41