I have been building PickTests one small browser test at a time.

The project currently includes six tests: reaction time, aim training, sequence memory, number memory, multiple object tracking, and the Stroop test.

After finishing the sixth test, my natural next step was to start planning the seventh. A new test would give the homepage another card, create another page that could be discovered through search, and give me something visible to announce.

Instead, I went back to the reaction test.

The reason started with a simple question.

I had shared the development process on Indie Hackers, and one person asked:

Why would someone return after completing a test once?

I did not have a good answer.

The product promise was ahead of the product

The PickTests homepage already encouraged people to repeat tests, compare their scores, and see whether they improved.

That sounded right to me.

Users did not need an account, and they did not have to compete with a global leaderboard. They could simply test themselves today, return later, and compare their performance with their own previous results.

The problem was that the website did not remember much.

A user could finish a test, see a score, close the page, and return the next day. The page would behave as though nothing had happened before.

The product allowed repeated attempts, but the comparison still depended on the user remembering an old number.

I had considered adding recent results and personal bests before. It was not a new idea created by one comment. I had simply kept postponing it because building another test always felt like more visible progress.

That question made the gap harder to ignore.

One test flow did not fit every user

The reaction test was one of the first pages I revisited.

Its basic logic is simple. The page waits for a random amount of time, displays a signal, and measures how quickly the user responds.

The first working version was not difficult to build. The more difficult question was how many rounds one test should contain.

An earlier version required eight rounds.

There was a reasonable argument for it. A single result can be affected by distraction, an accidental click, the input device, or simple luck. Multiple attempts produce a more stable average.

But eight rounds also felt long for someone who only wanted to try the test once.

I considered five rounds, eight rounds, and ten rounds. Each number had an explanation, but none of them worked for every visitor.

Eventually, I stopped trying to find one perfect number.

The current reaction test offers two options:

- A single round for someone who wants a quick result

- Five rounds for someone who wants a more stable average

This was not a major new feature. It was simply an acknowledgement that people arrive with different levels of intent.

Some visitors are curious and want to click once. Others want to repeat the test and compare several attempts. The product did not need to force both groups through the same flow.

A lightweight product still needs memory

After changing the test modes, I added local result tracking.

The reaction test can now keep recent results, a personal best, and an average score in the browser. No account is required, and the data is not sent to a user profile or database.

Using localStorage has obvious limitations.

The data does not follow the user to another device. It can disappear if browser storage is cleared. It is not a replacement for an account system.

For this stage of the product, however, it is enough to connect one session with the next.

When someone returns, the page no longer starts from complete ignorance. The user can see what happened recently and whether the latest attempt is closer to a personal best.

I still do not know whether this will meaningfully improve retention.

The traffic is too small for me to claim that recent scores or personal bests make people return. Adding a return loop does not prove that users will use it.

But the product now supports the promise it already made.

If a website tells users to compare themselves over time, it should preserve something worth comparing.

The result screen is part of the product

Before this change, I thought of the result screen mainly as the end of a test.

Now I see it as the point where the next session can begin.

A result page can show:

- What happened in the current attempt

- How it compares with recent attempts

- A personal best

- A simple reason to try again

The difficult part is deciding how much information to include.

Showing only one number can feel empty. Adding charts, rankings, detailed analysis, sharing buttons, and multiple statistics can turn a lightweight test into a dashboard.

I am still looking for the right balance.

I also want to be careful with external benchmarks. Reaction time can vary by device, browser, mouse, keyboard, and touch input. A label such as “above average” looks useful, but it should be based on a trustworthy comparison rather than a number added to make the result screen feel complete.

For now, personal history is more honest than pretending to know exactly how a user compares with everyone else.

Why I postponed the seventh test

After reviewing the reaction test, I opened the other five pages again.

Individually, they worked. Together, they did not always feel like parts of the same product.

Some tests displayed results immediately. Others paused before showing them. Some result pages explained the score clearly, while others mainly displayed a number. Some interactions felt natural on mobile, while others still reflected desktop assumptions.

None of these issues looked severe when I checked one page at a time.

They became more noticeable when I used several tests in one session.

Starting the seventh test would not solve those inconsistencies. It would only add another page that might need the same work later.

So the seventh test is still waiting.

I am currently spending more time on the existing pages: result consistency, mobile interactions, local history, and the small details that are difficult to announce as new features.

That work does not produce another card on the homepage.

It may not produce an obvious traffic increase either.

But it makes the six existing tests feel less like separate experiments and more like one product.

More features are not always more progress

The main lesson for me was not that every website needs localStorage or a personal-best score.

It was that feature count can hide unfinished product decisions.

A test can work technically while still failing to support the behavior the product encourages. A homepage can promise progress tracking while the individual pages forget every previous visit.

Building another feature is visible progress. Returning to an existing page often feels slower and less exciting.

Sometimes it is still the more important work.

You can try the reaction test here: Reaction Time Test

The rest of the current tests are available on PickTests