I recently started building PickTests, a collection of small browser-based tests for reaction time, memory, focus, speed, and coordination.
At the beginning, I thought this would be a relatively simple project.
A reaction time test needs a timer. A sequence memory test needs a few blocks. An aim trainer needs targets that appear in different positions.
The basic idea behind each test is easy to understand, and the first working version can often be built quickly.
But after working on several tests, I realized that getting the code to work was only the beginning.
Why I started PickTests
I have used many browser-based benchmark and skill-testing websites over the years.
Some of them are useful, but the experience often feels inconsistent. One test looks modern while another feels unfinished. Some pages are difficult to use on mobile. Others are filled with so many unrelated elements that the test itself becomes hard to focus on.
I wanted to build something simpler.
The idea behind PickTests is straightforward:
Choose a test, understand it quickly, complete it, see your result, and try again.
There is no account to create, no software to download, and no long setup process.
I am not trying to build a professional assessment platform. PickTests is meant to be a lightweight place where people can test themselves, compare their own results, and come back when they want to try again.
Building the first version was the easy part
The first test I worked on felt surprisingly manageable.
The screen changes state, the user reacts, the browser measures the time, and the result appears.
Once that worked, I thought the difficult part was mostly finished.
It was not.
Small questions started appearing everywhere.
What should happen when someone clicks too early?
How long should the random waiting period be?
Should the result be based on one attempt or several rounds?
What happens when the user switches tabs halfway through the test?
How should the same interaction work on a phone?
None of these problems looked large on their own, but together they determined whether the test felt reliable or frustrating.
That became a repeated pattern throughout the project.
The basic logic was usually simple. The experience around that logic required much more thought.
Small details can change the entire test
An aim trainer is a good example.
The main interaction is simple: show a target, let the user click it, then move it somewhere else.
But target size changes the difficulty. The distance between targets changes the pace. The size of the playable area changes everything again on mobile devices.
Even the way a target is positioned matters. If part of it appears outside the playable area, the test immediately feels unfair.
The same is true for memory tests.
A sequence can be displayed correctly, but the test may still feel wrong if the animation is too fast, too slow, or unclear. The user should know when to watch and when to respond without needing to think about the interface.
These details are not advanced technical problems. They are product decisions.
That was one of the biggest lessons for me.
A small browser tool can have very little code and still require a surprising amount of design thinking.
Consistency became more important as the project grew
PickTests currently includes several different types of tests, including reaction time, aim, sequence memory, number memory, visual tracking, and attention-based tests.
Each one has its own rules, but I do not want them to feel like unrelated pages collected under the same domain.
The instructions should use a similar tone.
Buttons should behave consistently.
Results should be easy to understand.
Restarting a test should feel familiar.
Mobile interactions should not feel like a reduced version of the desktop experience.
As I added more tests, I started spending more time on the shared experience between them.
This made me slow down.
Instead of adding as many tests as possible, I decided to improve the existing ones before expanding too quickly.
A large number of unfinished tests may make the website look bigger, but it does not make it better.
I would rather have fewer tests that feel complete.
Why I kept the technology simple
PickTests is built with plain HTML, CSS, and JavaScript.
There is currently no frontend framework, backend, database, or account system.
This was not a statement against frameworks. I simply did not need one for the current version.
Each test has a limited number of screens and states. Keeping the technology simple makes it easier for me to understand every part of the interaction and adjust it quickly.
It also fits the product.
A user should be able to open a test and begin almost immediately. The website does not need a complicated application structure to provide that experience.
Using a simple technical foundation has allowed me to spend more time on the parts users can actually feel: timing, feedback, spacing, difficulty, mobile behavior, and result clarity.
The result is more than a number
At first, I treated the result screen as the final step.
The test ends, a number appears, and the job is done.
But a number without context is not always useful.
If someone gets a reaction time of 240 milliseconds, they may wonder whether that is good, average, or poor.
If a memory test ends at level eight, they need to understand what the level represents.
Users also need to know whether a higher or lower score is better and what they can do next.
The result screen is not separate from the test. It is part of the experience.
I am still working on this part.
I want results to be clear without turning every page into a long explanation. The goal is to give enough context while keeping the flow lightweight.
Building for mobile changed many decisions
It is easy to build a browser test while sitting in front of a desktop monitor.
The problems become more obvious when the same test is opened on a phone.
The screen is smaller. Touch input is different from mouse input. Browser controls reduce the usable height. Accidental touches are more common. The device may rotate halfway through a test.
A layout that feels spacious on desktop can become crowded on mobile.
A target that looks reasonable with a mouse may feel too small for a finger.
Because of this, mobile support cannot be something added after the desktop version is finished.
It influences the test itself.
This is one of the areas I am continuing to improve across PickTests.
PickTests is also a learning project
Beyond building the tests, PickTests is my attempt to learn how to grow an English-language web product from zero.
I am an independent developer, and this is still an early project.
There is no large team, existing audience, or launch campaign behind it.
I am learning how to choose useful tests, create pages people can understand, improve the experience, and gradually make the website discoverable through search.
That process is slower than simply publishing new pages.
It requires deciding what is actually worth building and whether each page gives users a reason to stay, try again, or return later.
I do not know yet how far the project will go, but that uncertainty is part of why I find it interesting.
What I am working on next
For now, my priority is not adding dozens of new tests.
I am improving the tests that already exist.
I want to make the difficulty more balanced, the mobile experience more reliable, and the result pages more useful.
After that, I plan to explore more tests related to typing speed, attention, memory, and coordination.
But I want each new test to earn its place on the website.
PickTests is still small, but building it has already changed how I think about small web tools.
The code may be simple.
The idea may be easy to explain.
But making a tool feel clear, fair, and worth using again is where most of the real work begins.
You can try the current version here:
I would be interested to hear what feels good, what feels confusing, and which parts still need improvement.
Top comments (1)
Nice launch — the honesty about browser-test pain is refreshing. I ran my usual launch-day scan on picktests.com and wanted to share, since you're clearly in ship mode:
What's solid: HTTPS with a valid TLS 1.3 cert (83 days left), nosniff, strict Referrer-Policy, clean SEO basics (title, meta, single H1, robots + sitemap all good), 370ms response.
Two gaps worth closing before real users poke at it:
Strict-Transport-Security: max-age=31536000; includeSubDomainsdefault-src 'self'in report-only mode and tighten from there.Also
X-Frame-Options: DENY(or CSPframe-ancestors) kills clickjacking for free.Happy to send over the full scan report if useful — I do free launch-readiness scans for new products, just say the word. Good luck with PickTests!