The product sounds tiny: count taps for 10, 30, or 60 seconds. The interesting part is making that count credible.

Why a custom tool

Most tap-speed apps are built for casual play. Competition use has different requirements:

• work offline
• run well on an iPad
• avoid accidental browser gestures
• count multi-finger input correctly
• preserve enough raw data to audit a run
• keep history locally without accounts

For this use case, simplicity matters more than visual novelty.

Input model

TapSurge uses pointerdown and active pointer tracking. The key rule is that holding a finger down should not count repeatedly. A tap is a new press, not a frame, animation event, or repeated touch state.

The app records:

• total taps
• average CPS
• one-second live CPS
• maximum live CPS
• maximum simultaneous fingers
• raw timestamps and pointer IDs

That raw data is important. It lets a run be inspected after the fact instead of trusting only the final number.

Offline design

The app is intended to work in a PWA-like mode. It has a local app shell, a service worker, and no backend dependency during play.

This is one of those projects where offline support is not a nice extra. It is part of the user story. If the tool is used at a booth, in a classroom, or during a small event, network dependency is unnecessary risk.

UI constraints

The UI has to be obvious under pressure. A player should not be reading instructions while the timer is running.

The controls are intentionally few:

• choose duration
• start
• tap
• see result
• review history
• export evidence if needed

The harder work is preventing the browser from interfering: double-tap zoom, scroll gestures, safe-area issues, and fullscreen behavior all matter more on a real iPad than in a desktop browser.

What I learned

Small event tools benefit from being boring. The best version is not the most animated one; it is the one that produces trustworthy results with minimal setup.

TapSurge is a good example of a private tool that could be public, but does not need a large roadmap. Its scope is the feature.

The important constraint is that there is no backend inference service. The browser is not just the UI; it is also the runtime.

Why build it

Most translation tools are service-shaped: text goes to a server, the server runs a model, and the result comes back. That is fine for many cases, but it is also more infrastructure than I wanted for a narrow personal tool.

PocketBabel asks a smaller question: if the scope is only English to Chinese and Chinese to English, can the whole product be a static site?

That decision makes the system easier to reason about:

• no API key
• no account system
• no backend deployment
• no request logging
• no server-side scaling problem

The cost is that the first model download matters and browser performance becomes part of the product.

Product boundary

The project intentionally avoids becoming a general translation platform. The current shape is narrow:

• English to Chinese
• Chinese to English
• text input and output
• desktop and mobile browser support
• PWA shell and offline reuse

It does not try to support OCR, speech, synced history, arbitrary language pairs, or collaborative workflows. Those features are tempting, but they would change the project from a useful small app into a maintenance surface.

Technical shape

The implementation is a React and Vite app. Translation is handled by transformers.js with browser-side model loading and caching. Deployment is static, which makes Cloudflare Pages a natural fit.

The UI challenge is not only making a textarea and a button. The app needs to explain model state without becoming noisy:

• model not downloaded yet
• model loading
• translation running
• offline reuse available
• failure state when the browser cannot support the runtime well

For an app like this, good status text is part of the architecture. If users do not know whether the model is downloading, warming up, or stuck, the app feels broken even when the code is doing the right thing.

What I learned

Browser AI is practical when the product scope is narrow. It is much less practical when you pretend the browser is a free replacement for a server.

The useful pattern is:

1. choose a task with a clear input and output
2. constrain the model set
3. make loading and caching behavior visible
4. avoid account and sync features unless they are essential

PocketBabel works because it does not try to be Google Translate. It is a small translation surface for a small set of language directions.

Open source status

PocketBabel is public because the architecture is self-contained and does not rely on private infrastructure. It is also a good example of the kind of project that benefits from being inspectable: the privacy story is stronger when the code path is visible.