Data-driven web application / Active
Ahhgela Ledger
Ahhgela Ledger exists because the sticker pack does not have a full authoritative catalogue I can simply import. The app has to track what appears to exist while keeping uncertain entries visibly separate from verified ones.
I built a React and TypeScript collection workspace that separates catalogue state from collection counts, derives needed and extra quantities, and keeps repeated edits fast across desktop and mobile views.
- Role
- Sole developer
- Focus
- Product, frontend, and data modelling
- Maturity
- Active
- Access
- Public browsing; private admin tools
- Technologies
- React
- TypeScript
- Vite
- Node.js
- Last reviewed
- Aug 2026
The problem
What the project had to handle
The harder part is that catalogue status and collection state are different questions. A sticker can be a possible entry while still needing owned, target, needed, and extra quantities for planning.
A Pokémon appearing in the reference dataset does not prove that an Ahhgela sticker exists.
Key decisions
The shape of the build
Separate catalogue status from quantities
Verified, possible, under review, and excluded entry states stay separate from owned and target counts.
That keeps reference data from becoming a verified collection claim.
Derive needed and extra quantities
Needed and extra states are computed from owned and target values instead of hand-maintained.
The ledger can show what to look for next and what is surplus without becoming a binary checklist.
Optimise repeated edits
Filters, region groups, quick-edit controls, and mobile layout support many small collection updates.
The interface fits the actual collection rhythm instead of making every sticker change feel like form work.
How it works
End-to-end flow
Generated catalogue data and runtime admin overlays feed the collection interface. The app groups entries by region, filters by verification status, collection state, and shiny variants, derives counts from owned and target values, and keeps protected edit paths separate from the public browsing surface.
What I implemented
The working surface
Catalogue model
- Generated TypeScript corpus data from tracked source files.
- Separated reference entries, verified sticker evidence, and uncertain candidates.
- Preserved region grouping and shiny/variant states for browsing.
Collection workflow
- Tracked owned, target, needed, extra, collected, and missing states.
- Built filters and regional navigation for dense sticker-grid browsing.
- Refined repeated-edit flows for desktop and mobile use.
Protected editing
- Added server-backed single-admin login for protected edit tools.
- Used runtime overlays for count and verification changes.
- Kept admin editing private while leaving public browsing available.
Data and operations
- Documented public-output, auth, secrets, TLS, ports, and build expectations.
- Kept protected admin editing separate from the public browsing surface.
- Recorded operational checks around protected mutation and restoration paths.
Validation
Checks and evidence
Public browsing route observed
The collection ledger route was checked as a public browsing surface; protected editing remains private.
make check passed
`make check` passed; Vite reported a non-blocking chunk-size warning.
Catalogue and collection state separated
Catalogue status and collection quantities are separate in the implementation.
Catalogue counts still being reconciled
Public and local catalogue counts are still being reconciled, so no catalogue total is shown.
Current state
Active public browsing surface with private admin editing.
Catalogue status and collection quantities remain separate; the app does not claim an authoritative or complete catalogue.
Public and local catalogue counts are still being reconciled, so no catalogue total is shown.