minecraft java and bedrock use completely different pack structures. porting a pack between them takes at least 30 minutes, even for an experienced porter. that friction kept most packs locked to one edition, and most players locked out of half the ecosystem. i wanted every user to get a frictionless experience, whether they’re porting or just downloading.
/ what i did
leaned on my architecture & design background to build an ecosystem, not a single site. everything a player or creator would need to get a pack painlessly. a port bot that handles the java ↔ bedrock conversion, a pack gallery to browse and download, and an in-progress pack builder on the site itself. built solo. product, design, engineering, seo, community ops.
/ iii. technical deep-diveoptional · expand
/ architecture
two repos, one ecosystem, one database. the website renders the gallery, search, and the in-progress pack builder. the bot handles ingestion and porting: creators drop packs in discord, the bot parses, converts between java and bedrock, stores assets, and writes straight into the shared postgres. both services run on one server, composed with docker, fronted by cloudflare. ci is github actions: build, typecheck, image push, deploy. the code itself stays private; the linked repos hold detailed readmes that walk through how each piece works.
/ learnings & what i’d change
honestly the lessons are pretty simple. first: the community skews very young, and you can’t assume the bar of attention you’d expect from adults. standard discord features like pinned messages, forum tags, or the help command just get ignored. your ux has to meet them where they are, not where the platform thinks they are. second: it’s exhausting chasing people whose accounts keep getting compromised on fishy servers. account safety and recovery flows turned out to be a bigger part of community ops than i ever planned for.
