OnTap
Menu

OnTap · Beat the Build

Use it. Then try to build it.

Small software should be fun to use and good enough to keep. Meet the benchmark: tools that work, respect your data and feel finished.

How long would your coding model take to match one? We call that Vybe Time.

Vybe Time Not measured

Make something worth keeping

Try Pixel Playground →

View brief

Build a browser-only pixel-art toy with a text seed, curated palettes, mirror symmetry, grid sizes and SVG download. Make it usable on a phone and with a keyboard. No remote generation service.

The finish line

  1. The same seed and settings produce the same grid; changing a setting changes the result predictably.
  2. Grid size and input length are bounded; exported SVG has only safe shapes and allowlisted colors.
  3. SVG downloads open correctly and omit seed text. Old object URLs are released.
  4. Keyboard controls, useful labels and a narrow-screen layout work. Inputs never leave the browser.

Challenge brief v1 · Tool 0.1.0

Vybe Time Not measured

Pretty JSON. Exact numbers.

Try JSON Formatter →

View brief

Build a browser-only JSON formatter and minifier that preserves numeric tokens, including very large integers, and gives useful invalid-input errors. Include copy and an accessible mobile layout.

The finish line

  1. Formatting and minifying preserve values, array order, large integers and decimal tokens without lossy number parsing.
  2. Invalid input gets a useful error; stale output is cleared after edits.
  3. Processing has a finite input limit; copied output matches the displayed result.
  4. Keyboard and narrow-screen usage work. JSON contents never enter requests, logs or analytics.

Challenge brief v1 · Tool 0.1.1

A clock with a quality bar

No model times have been published yet. These briefs are open challenges, not a model leaderboard. Trying a challenge does not submit a research result or send us your code.

  1. Same starting line. Freeze the brief, starter repository, environment, allowed tools, model revision and settings. Keep cold-start and assisted-rebuild runs separate.
  2. Stop at a verified build. Measure elapsed time from the first prompt to the candidate that passes independent checks. Keep failures, timeouts, retries, cost and human help in the record. Deployment time is separate.
  3. Show the evidence. Publish repeated-run results with pass rate, sample size, range and the exact model/setup. A quick broken demo does not win.
  4. Label predictions. Estimates will need real calibration and held-out validation. A coding-benchmark score alone cannot tell us how many minutes a tool takes.

Our first control runs will use the OpenAI models in our development workflow, with exact model identity recorded when each run happens. No speed, quality or provider ranking is implied before those tests.

We are keeping a versioned research format so results can later support independent analysis. Researcher API access is a future release; no data submission or API is open here.

Evaluation reference: OpenAI evaluation best practices.

Find your next useful—or just fun—tool →