Browser product engineering / CASE STUDY
A local-first learning platform
Giving multiple learning activities a consistent shell, shared preferences, and progress that stays on the device.
An anonymous account of an individual product or tool I’ve worked on. Product identity and identifying operational details are withheld; the stack and engineering decisions describe implemented work.
- My role
- Platform structure, game integration, shared browser services, and unit/browser checks.
The problem
Independent mini-apps quickly develop inconsistent controls and duplicate settings. The platform needs a coherent experience while keeping each activity's rules separate and allowing local progress without an account.
Stack & system flow
- TypeScript
- Vite
- DOM APIs
- Vitest
- Playwright
A framework-free TypeScript application shares its launcher, localization, storage, and audio conventions across activities. Vite builds the static application; tests exercise both the shared platform and individual activities.
Simplified flow
- Launcher
- Activity registry
- Game logic
- Shared services
- Local progress
Engineering decisions
Share the platform, separate the rules
An activity registry connects the launcher to individual games. Localization, sound preferences, profiles, and progress use shared services instead of being reimplemented separately in every activity.
Choose device-local progress
Profiles and progress are stored in a versioned browser state. This keeps the core experience independent of sign-in and synchronization, while making the loss of browser data and lack of cross-device continuity explicit tradeoffs.
Distinguish playable work from planned work
The registry marks implemented activities separately from placeholders. That distinction matters when evaluating the product: a slot in a launcher is not evidence of a finished game.
What was implemented
The repository contains a reusable launcher and implemented learning activities with shared localization, audio, preferences, and progress. New activities can use the same platform conventions without sharing their game-specific rules.
Representative regression coverage
- Storage checks cover profile progress, preferences, incompatible versions, and defaults for newly added settings.
- Unit coverage exercises the registry, localization, and individual activity rules.
- Browser smoke coverage exercises the launcher and implemented games.
These examples describe repository tests reviewed for this case study, rather than a new production audit.
Tradeoffs & limits
Local progress does not synchronize across devices and can be cleared with browser data. Some activities remain planned; the case study's implementation claims apply to the playable subset.