Здравствуйте! Меня зовут Сергей, Full-Stack разработчик (React, Next.js, Node.js/Express, PostgreSQL, Docker). Веду проекты от архитектуры до деплоя и дальнейшей поддержки самостоятельно, готов к долгосрочному сотрудничеству.

Похожие по архитектуре проекты: — Внутренний web-портал ГБУЗ ИКБ №1 ДЗМ (2,5 года, ведущий инженер-программист): личные кабинеты с ролевой моделью на JWT, разграничение прав доступа на уровне интерфейса и запросов к БД, работа с медиаданными и файлами, отчётность и выгрузки. — «ДомСтрой» (Next.js 14 + Express + TypeScript + Prisma + Docker + CI/CD): https://house-construction-delta.vercel.app — repository pattern для слоя данных (переключение источника без изменения API), оптимизация изображений (next/image + sharp), формы с валидацией на Zod. — «МедАудит» (React 18 + Vite + Zustand): https://medaudit-hub.vercel.app/ — ролевая модель с гейтами доступа по экранам, работа напрямую с заказчиком, два раунда доработок по фидбеку.

1. Стек для такого проекта Next.js (SSR/SSG для публичных страниц и SEO) + Node.js/Express или Next.js API-роуты для бэкенда + PostgreSQL. Next.js даёт быстрые страницы для привлечения новой аудитории (важно при переносе с чужой платформы) и гибкий рендеринг для закрытого контента за авторизацией. PostgreSQL — под подписки, права доступа и историю платежей, где нужна консистентность. Хранение фото/видео — через объектное хранилище (S3-совместимое) с подписанными временными ссылками, а не напрямую с сервера, чтобы закрытый контент нельзя было получить по прямому URL. Recurring-платежи и webhooks в проде у меня в опыте пока не было, но это стандартная и хорошо документированная задача — разберусь без проблем, подберём провайдера под ваши требования.

2. Задел под подключение других авторов в будущем Уже на MVP заложил бы в модели данных сущность «автор» как отдельную таблицу, а не хардкодил один аккаунт: весь контент, подписки и платежи с самого начала привязывать к author_id, даже если автор пока один. Роли и права делать через ту же ролевую модель, что использовал в личных кабинетах (JWT + проверка прав на backend), — тогда добавление роли «автор» с собственным кабинетом позже не потребует переписывать авторизацию. Слой доступа к данным вынести в отдельный repository-подобный модуль, как я делал в «ДомСтрое», чтобы переход от одного автора к множеству был заменой запросов, а не переделкой API.

3. Что упростил бы в первой версии Не делал бы гибкую multi-author логику сразу (только задел в структуре данных, см. п. 2) — интерфейс управления несколькими авторами добавляется по факту появления второго. Платёжную часть в MVP свёл бы к одному провайдеру и одному типу подписки, без сложных тарифов и промо-механик, — это можно нарастить после запуска. Личный кабинет в первой версии — минимальный (доступ к контенту, статус подписки, отмена), без расширенной аналитики для автора.

Подскажите, пожалуйста: какой платёжный провайдер вы сейчас используете на сторонней платформе, и его планируется сохранить или искать альтернативу? Для ню-контента подходят не все платёжные системы, это может сильно повлиять на выбор стека и архитектуру MVP.

По бюджету и срокам: готов обсудить после того, как вы пришлёте детали по продукту и бизнес-логике.