My Heroes Library
Owned units stay searchable and sortable, with merges, dupes, tags, and build-state summaries readable in one pass.
Quick Contact
Solo Project · Live-Service Companion App
FEH Barracks Manager started as a personal tool for Fire Emblem Heroes, then grew into a full product: synced barracks management, custom hero data ingestion, release-bundle distribution, and a portable launcher path for a game community that does not give you a stable API to work with.
Role
Solo developer across product design, frontend, data ingestion, release flow, and launcher packaging
Surfaces
Browser, mobile browser, and portable Windows launcher
Core Stack
Next.js 16, React 19, Supabase, custom Game8/Fandom pipeline, GitHub Releases
Current Local Scale
1270 indexed heroes, 1271 headshots, 5081 full-body images, and 1267 quote files
These current local captures show the parts of the app that matter most on a portfolio page: the synced barracks shell, the owned-library grid, the Tavern social layer, and the Aether Resort prototype that turns roster data into something more playful.
My Heroes Library
Owned units stay searchable and sortable, with merges, dupes, tags, and build-state summaries readable in one pass.
Tavern Social Surface
The Tavern pushes the product past plain CRUD by giving the collection app a social lounge, avatar stage, and friend-state layer.
Aether Resort Prototype
Local mini sprites, slot selection, and saved background preferences turn collection data into a playful companion surface.
Synced Entry Surface
The account entry flow frames the tool as a synced multi-device product instead of a local-only prototype.
Fire Emblem Heroes creates a very specific product problem. Players are not only tracking owned units. They are tracking merge projects, dupes, skill plans, favorites, team ideas, and a roster that keeps changing under them. I wanted one place to keep that state usable across devices without pretending the data side would stay simple.
That pushed the project into real systems work very quickly. The app had to feel like a real collection manager, but it also had to survive unstable source coverage, naming mismatches, release maintenance, and the cost tradeoffs of shipping a lot of FEH art.
App Product
The app layer handles auth, account-bound user state, hero browsing, barracks CRUD, My Heroes editing, Aether Resort, Tavern, and the AI export surface.
Data Pipeline
Behind the UI is a custom FEH dataset built from Game8 and Fandom. Game8 stays the canonical identity source, while Fandom fills in art, quotes, and shared assets.
Distribution
The project also ships as a portable Windows launcher that installs update bundles from GitHub Releases and keeps the heavier local asset path viable.
Upstream Data Was Not Stable
This was never a clean API integration. The project had to survive roster drift, naming mismatches, lazy-loaded discovery gaps, and repeated importer hardening work.
Cloud Sync And Heavy Art Needed Different Homes
I kept user metadata in Supabase, but treated the full FEH art archive as local release-bundle material. That kept the app useful without pushing storage costs in the wrong direction.
Release Quality Mattered
This project needed real maintenance habits: scheduled imports, reconcile checks, launcher updates, asset bundles, release notes, and safer fallbacks when source data drifted.
I already had a local FEH case-study pack and release notes in progress, so I turned that material into a cleaner evidence viewer here. It shows the project summary, the current architecture/scale snapshot, and the release-hardening direction instead of asking the page to stand on portfolio copy alone.
FEH Barracks Manager is one of the clearest examples of how I work when a project gets real. It is not just interface work and it is not just backend plumbing. It is product definition, data reliability, cost-aware architecture, release discipline, and enough user empathy to keep the tool practical even when the source data underneath it keeps moving.