My Heroes Library
Owned units stay searchable and sortable, with merges, dupes, tags, and build-state summaries readable in one pass.
Solo Project · Live-Service Companion App
A Fire Emblem Heroes companion app for tracking owned characters across devices. I built the interface, cloud sync, data importer, release bundles, and portable Windows launcher without access to an official game API.
Role
Solo developer: product design, frontend, data ingestion, releases, 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
1,270 indexed heroes, 5,081 character images, and 1,267 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 combines interface design, data ingestion, cost-aware architecture, packaging, and updates. The release workflow keeps the tool usable while its source data changes and lets another person launch it without rebuilding my development environment.