MaxDonate
A donation store platform for Minecraft servers. A player buys on the storefront, a webhook confirms the payment, and the item is delivered in-game over RCON, even if the player is offline. I designed the product and the landing and built the stack with a team of AI agents.
- 01 — Project
- MaxDonate
- Role
- Product Designer & Developer — end to end
- Scope
- Product strategy, Architecture, Landing & storefront UI, Dashboard UX, Mobile app for owners, Full-stack development, AI agent workflow
- Stack
- Next.js, NestJS, PostgreSQL, Prisma, Redis, BullMQ, Docker, TypeScript, React Native, Expo, Claude
02Context
Minecraft servers live on donations: players buy ranks, kits and items. Most donation stores need a plugin on the server and trust the browser that a payment went through.
The flow I designed: Player → Storefront → Checkout → Payment provider → Verified webhook → Order → Persistent delivery queue → RCON worker → Minecraft server → Delivery result.
03Problem
For a server owner the worst case is a paid order that never reaches the player.
- P1Plugins mean installation, version conflicts and access to the server.
- P2If the player is offline or the server lags, delivery fails silently.
- P3Payment shown as “paid” in the browser is not proof of payment.
04Research & discovery
Methods
- Analysis of existing donation platforms and how they deliver purchases
- Survey for early-access server owners (built into the landing)
What I found
- Most stores need a plugin on the server, and owners are wary of it: version conflicts and giving access to the server.
05UX
Information architecture
Core flow
- 01Storefront
- 02Checkout
- 03Payment
- 04Verified webhook
- 05Delivery queue
- 06Item in game
- Server owner dashboard: servers with RCON test, storefront, categories and products, promo codes, orders, revenue, balance with payouts, team.
- Mobile app for owners (React Native, Expo): sign in, 30-day revenue with a chart, orders with search and filters, a retry button for failed deliveries, servers with an RCON check. Read-mostly, with no secrets on the phone.
- The buyer gets a public order page and can see the delivery status.
Key decisions
D1RCON instead of a plugin
- Problem
- Plugins are the main friction: install, update, conflicts.
- Decision
- Deliver over RCON, which every server already has. Nothing to install.
- Why
- Setup is “enter address and password, press Test”.
D2A delivery queue, not a request
- Problem
- If the server is down at the moment of payment, a direct command is lost.
- Decision
- Every paid order becomes a persistent job with retries, visible in the dashboard.
- Why
- “The donation always reaches the player” is guaranteed by the architecture.
06Design
Dark, game-style look with pixel accents: familiar to players, clear enough to trust with a purchase.
- The landing explains the product with the product itself: a live delivery log, an interactive hotbar, a storefront preview.
- Every technical guarantee is written as a benefit for the server owner.
07Development
Designed and built by me
A monorepo built with a team of Claude agents. I set the product, rules and architecture; the agents implement, test and document.
- Next.js web app, NestJS REST API, BullMQ worker for delivery; PostgreSQL + Prisma, Redis; Docker.
- Ten rules for the agents, e.g. idempotent payment events, no RCON calls inside HTTP requests, no secrets on the client.
- Definition of Done for every feature: types, tests, authorization, docs.
08Final product
09Outcome
- The product is built and ready for rollout: landing, owner dashboard, storefront, order tracking and a first version of the mobile app all work.
- Next: launch with the first server owners, collect their feedback and usage data, then connect real payments.
10Reflection
You can put a product together fast with AI agents, but the architecture still has to be thought through by me: the agents carry things out, the decisions stay mine.