MaxDonate
Платформа донат-магазинів для Minecraft-серверів. Гравець купує на вітрині, вебхук підтверджує оплату, а товар видається в грі через RCON, навіть якщо гравець офлайн. Я спроєктував продукт і лендинг та зібрав стек із командою AI-агентів.
- 01 — Проєкт
- MaxDonate
- Роль
- Product Designer і розробник — повний цикл
- Обсяг
- Продуктова стратегія, Архітектура, UI лендингу й вітрини, UX кабінету, Мобільна апка для власників, Full-stack розробка, Робота з AI-агентами
- Стек
- Next.js, NestJS, PostgreSQL, Prisma, Redis, BullMQ, Docker, TypeScript, React Native, Expo, Claude
02Контекст
Minecraft-сервери живуть на донатах: гравці купують ранги, набори й предмети. Більшість магазинів вимагає плагін на сервері й вірить браузеру, що оплата пройшла.
Шлях, який я спроєктував: Гравець → Вітрина → Оформлення → Платіжний провайдер → Перевірений вебхук → Замовлення → Постійна черга доставки → RCON-воркер → Minecraft-сервер → Результат доставки.
03Проблема
Найгірше для власника сервера — оплачене замовлення, яке не дійшло до гравця.
- P1Плагіни — це встановлення, конфлікти версій і доступ до сервера.
- P2Якщо гравець офлайн або сервер лагає, видача мовчки зривається.
- P3Статус «оплачено» в браузері — не доказ оплати.
04Дослідження
Методи
- Аналіз наявних донат-платформ і того, як вони доставляють покупки
- Опитування для власників серверів у ранньому доступі (вбудоване в лендинг)
Що я з’ясував
- Більшість магазинів вимагає плагін на сервері, і власники цього бояться: конфлікти версій і доступ до сервера.
05UX
Інформаційна архітектура
Основний шлях
- 01Вітрина
- 02Оформлення
- 03Оплата
- 04Перевірений вебхук
- 05Черга доставки
- 06Предмет у грі
- Кабінет власника: сервери з перевіркою RCON, вітрина, категорії й товари, промокоди, замовлення, дохід, баланс із виплатами, команда.
- Мобільна апка для власників (React Native, Expo): вхід, дохід за 30 днів із графіком, замовлення з пошуком і фільтрами, кнопка «Повторити видачу», сервери з перевіркою RCON. Здебільшого для перегляду, без секретів на телефоні.
- Покупець отримує публічну сторінку замовлення й бачить статус доставки.
Ключові рішення
D1RCON замість плагіна
- Проблема
- Плагіни — головне тертя: встановлення, оновлення, конфлікти.
- Рішення
- Доставляти через RCON, який уже є на кожному сервері. Нічого встановлювати.
- Чому
- Налаштування — «введи адресу й пароль, натисни Перевірити».
D2Черга доставки, а не запит
- Проблема
- Якщо сервер лежить у момент оплати, пряма команда губиться.
- Рішення
- Кожне оплачене замовлення стає постійним завданням з повторами, видимим у кабінеті.
- Чому
- «Донат завжди доходить до гравця» гарантує архітектура.
06Дизайн
Темний ігровий стиль із піксельними акцентами: знайомий гравцям і достатньо чіткий, щоб довіряти покупку.
- Лендинг пояснює продукт самим продуктом: живий лог доставки, інтерактивний хотбар, прев’ю вітрини.
- Кожна технічна гарантія описана як вигода для власника сервера.
07Розробка
Спроєктував і зібрав сам
Монорепозиторій, зібраний з командою агентів Claude. Я задаю продукт, правила й архітектуру; агенти реалізують, тестують і документують.
- Next.js веб-застосунок, NestJS REST API, BullMQ-воркер доставки; PostgreSQL + Prisma, Redis; Docker.
- Десять правил для агентів, напр.: ідемпотентні події оплати, жодних RCON-викликів усередині HTTP-запитів, жодних секретів на клієнті.
- Критерій готовності для кожної функції: типи, тести, авторизація, документація.
08Фінальний продукт
09Результат
- Продукт зібраний і готовий до запуску: лендинг, кабінет власника, вітрина, відстеження замовлень і перша версія мобільної апки працюють.
- Далі: запустити з першими власниками серверів, зібрати відгуки й дані, а потім підключити реальні платежі.
10Висновки
З AI-агентами продукт можна зібрати швидко, але архітектуру все одно продумую я: агенти виконують, а рішення лишаються за мною.