Collection and planning data system / Development build
PoGO Tracker
PoGO Tracker is a collection workspace for Pokémon GO records. The goal is to bring imported collection data, storage clean-up, PvP review, raid planning, candies, and account-scoped decisions into one inspectable web interface.
I built a development-stage Next.js, React, Prisma, and PostgreSQL ledger with public staged demos, database-backed app accounts, protected collection views, import scaffolding, source-sync tooling, and raid-attacker planning surfaces.

- Role
- Sole developer
- Focus
- Collection tooling and planning workflows
- Maturity
- Development build
- Access
- Public staged demos; protected account routes
- Technologies
- Next.js
- React
- TypeScript
- Prisma
- PostgreSQL
- Last reviewed
- Aug 2026
The problem
What the project had to handle
The hard part is that collection data, source snapshots, and recommendation surfaces have different levels of trust. A saved Pokémon record is user-owned data; PvPoke and DialgaDex inputs are source snapshots; raid and PvP views need to stay useful without becoming unsupported gameplay advice.
This is an unofficial fan tool for imported and exported collection data. It does not request Pokémon GO credentials, automate gameplay, imply affiliation, or present staged planning surfaces as recommendation accuracy.
Key decisions
The shape of the build
Account-scoped collection state
Database-backed app accounts separate each collection from shared reference and source-sync data.
That makes personal storage, editing, tagging, and planning decisions inspectable without collapsing them into global Pokémon data.
Staged public demos
The public homepage and raid-attacker demo use a separate saved collection dataset rather than live personal accounts.
The project can show the interaction model while keeping hosted multi-user readiness and ownership tests gated.
Trace planning views to source snapshots
PvPoke and DialgaDex sync tooling feed planning views as traceable inputs.
Raid and PvP surfaces can develop against source snapshots without claiming gameplay outcomes or recommendation accuracy.
How it works
End-to-end flow
Imported collection records, saved demo dataset, and PvPoke/DialgaDex snapshots feed a Prisma/PostgreSQL model. The web interface presents public staged demo surfaces, protected collection grids, filters, import paths, raid-attacker views, and account workflows while cross-user, recovery, backup, and recommendation gates remain tracked.
Collection workspace
PoGO Tracker
Account-scoped collection records support import review and planning views.
What I implemented
The working surface
Application and account shell
- Built a Next.js, React, TypeScript, Prisma, and PostgreSQL web/API base.
- Added database-backed login, signup, verification resend, password reset/change flows, sessions, and rate-limit records.
- Redirected protected routes to login while keeping public staged demos separate.
Collection workspace
- Built protected Pokémon grid and list views with search, filters, saved views, tags, and inspection/editing paths.
- Added Calcy IV import scaffolding and private import-file storage boundaries.
- Prepared collection workflows for storage clean-up, PvP review, candies, and raid planning.
Source-backed planning surfaces
- Added PvPoke ranking sync scripts and generated lookup helpers.
- Added DialgaDex raid ranking snapshot tooling with local snapshot fallbacks.
- Built public staged raid-attacker leaderboard and protected planning surfaces.
Development checks
- Configured production deployment assets and an active Nginx/TLS route.
- Validated public health and certificate hostname on 6 Aug 2026.
- Kept backup/restore, cross-user ownership, hosted recovery, and recommendation claims gated.
Validation
Checks and evidence
Development route reachable
The pogo-tracker.jaycapist.dev route, public health response, and certificate hostname smoke check were reachable on 6 Aug 2026.
Validation pass
`make check` and Finch Standards verification passed on 6 Aug 2026, with a documented Next build tracing warning rather than a failed build.
Staged demo surfaces
The public homepage demo and raid-attacker demo use a separate saved collection dataset.
Account and source work
The source includes database-backed app accounts, protected collection views, Calcy IV import scaffolding, and PvPoke/DialgaDex source-sync tooling.
Current state
Development build with public staged demos and protected account routes.
Demo data remains separate from account-scoped collections.
Cross-user ownership, restore, and recommendation evaluation remain incomplete.